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