Re: Guile support in GNU make

Hi Paul,

Paul D. Smith <[email protected]> writes:

> Over the last weekend I've been playing with adding (optional of course)
> support for Guile as an embedded scripting language into GNU make.

My problem is with the "optional" part. I think there are two broad
categories of users of GNU make: those that use GNU make for internal
projects and those that publish software that uses GNU make as a base 
of their build system.

For the former this could work since they can require GNU make that
is used internally to have Guile support. Thought, this is also not
a sure thing. Many places have policies such as "we use whatever
comes standard with Red Hat X.Y, period".

For the latter group the optional part is obviously a deal breaker
since there is no guarantee that the build of GNU make as used by 
the end user will have Guile support.

On the other hand, I also agree that making Guile a required component
is probably not an option either.

In fact, I have been doing some idle thinking about how we can resolve
this dilemma. I am not sure if you heard about the GCC plugin architecture
that has been added in 4.5.0. It is based on dynamic loading (dlopen)
and provides a C API that allows a plugin author to hook into various
places in the GCC compilation pipeline. It also allows the plugin to
register custom attributes and pragmas. I've been working with GCC
plugins for more than a year now, and it has been really, really
great.

This made me think that perhaps we could do something similar for GNU 
make. That is provide a way for a makefile to request the loading of a
plugin module. If the module does not exist, make can try to build it
and re-exec in exactly the same way included makefiles are handles right
now (this will allow the second category of users mentioned about to
distribute source code for their GNU make plugins together with their
software). 

Once loaded, a plugin is given a chance to register additional functions.
Maybe we can also define some additional hooks, like when up-to-dateness
of a file is determined, or before a command is executed. But I think just
extra functions will be a good first step.

The nice thing about the GCC plugin architecture is that the plugin
is loaded into the GCC address space. This means that it can access
all the functions, data structures, etc., that built-in GCC code can
access. I think the same approach will work fairly well for GNU make
as well.

And if we have something like this, it will be fairly straightforward
to add Guile support as just another plugin.

What do you think?

Boris

-- 
Boris Kolpackov, Code Synthesis      http://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++    http://codesynthesis.com/products/odb