Comment by nrclark | Hacker News Reader

Comment by nrclark | Hacker News Reader

Parent Full thread

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?".

I 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.

There 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.

Reply on news.ycombinator.com