Hacker News Reader

Comment by kazinator | Hacker News Reader

It is criminally under-integrated!

The only interface you get into the make internals from Guile is a function to expand a make expression, and a function to eval a makefile fragment.

These interfaces only encourage the use of Guile for nothing more than make metaprogramming, an area where more power is not needed.

Imagine if Guile access to the rules as data structures or something. And the graph of targets to be updated and what not.

Imagine if Guile could be used, say, to override the logic by which a target is considered out of date with respect to its prerequisites.

View on HN

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.

>Imagine if Guile could be used, say, to override the logic by which a target is considered out of date with respect to its prerequisites.

That is exactly what I was recently hoping for.

Make-as-library is such a compelling idea that I feel like it must have already been done, but I searched for something like this recently and the closest I found was Java's Ant, which gets the as-library part but sadly has no concept of "target is already up-to-date"...

Reply on news.ycombinator.com