Re: Guile support in GNU make

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Date: Sat, 14 Jan 2012 15:13:36 -0500
> 
>    The `make' program creates a new module, `gnu make', and exports
> these functions as public interfaces from that module:
> 
> `gmk-expand'
>      This GNU Guile function takes a single string as an argument.  The
>      string is expanded by `make' using normal expansion rules.  The
>      result of the expansion is converted into a string and provided to
>      GNU Guile as the result of the function.
> 
> `gmk-eval'
>      This function takes a single string as an argument.  The string is
>      evaluated by `make' as if it were a makefile.  This is the same
>      capability available via the `eval' function (*note Eval
>      Function::).  The result of the `gmk-eval' function is always the
>      empty string.
> 
> `gmk-var'
>      This function takes a single string as an argument.  The string is
>      interpreted as the name of a `make' variable, which is then
>      expanded.  The result of the expansion is converted into a string
>      and provided as the result of the function in GNU Guile.

But this cannot be enough to have a truly extensible Make, could it?
What these functions give us is building blocks for a kind of fancy
shell, which allows to define functions like the mkopen, mkwrite, and
mkclose examples you show.  (Btw, how come one needs to open and close
files in an extension language? this should be automatic, no?)

What I think is needed is to be able to affect Make on a more
fundamental level.  For example, control whether a target will be
remade given its prerequisites, or dynamically control the built-in
rules, or maybe access the dependency graph and do something with it.

For these "pipe dreams" to come true, Make should expose various hooks
at strategic places, so that a Guile program could use them to control
the build.  Without such hooks, we cannot consider Make to be truly
extensible, IMO.

Does this make sense?