4 ms·
100% agree. With the current API, there's no real advantage to using Guile over a C extension (other than the choice of language). If the Guile interface could
by nrclark 2y ago
100% agree. With the current API, there's no real advantage to using Guile over a C extension (other than the choice of language). If the Guile interface could hook into Make's dependency graph, it would be huge game-changer. But as it is, the Guile interface is basically a fancy macro processor.
The Guile interface can expand Makefile expressions into values, and can process/evaluate Makefile statements. But there's no way (that I've found) to do something like "remove this dependency from target X", ask "what dependencies does X currently have?", or ask "do you think X is currently up-to-date?".
- kazinator 2y agoI would say there is no advantage of using built-in Guile to call make's eval API over: $(eval $(shell <arbitrary-command>)) where arbitrary-command could run ssh to a virtual machine, running a docker container loaded with Common Lisp ... The Guile approach stays in one process, but that has no value in the context of make, which launches external programs as its principal paradigm.
- nrclark 2y agoThere is some benefit to Makefile processing speed, if that's a metric that affects your build. With one or two $(shell) calls, it won't matter at all. If you start to approach dozens or hundreds of calls, the extra overhead of all those shells can to be noticeable. Especially if your Makefile is automatically triggered on file changes or something.