On Thu, 2012-04-05 at 18:27 -0400, David Boyce wrote:
> A few years ago I suggested a plugin architecture much like this (but
> I didn't supply a patch - crucial difference), to allow a plugin to
> make the "up-to-date" determination, replacing the hardwired timestamp
> system. [...] Any idea how hard it would be to handle this with a plugin?
As make is currently implemented it's not really possible. That's not
to say it COULDN'T be and I do think this is a very useful goal, and I
certainly want to be sure whatever model we come up with can support
that, once it's possible. But before we can achieve it there will need
to be some cleanup in the algorithms make uses: we need to abstract
these things. Right now they're just kind of scattered inside other
functions (there is one main function but that's not the only place they
are handled).
> On an unrelated note, how would you anticipate plugins being loaded in
> real life?
The model I have today is a new processor definition "load", which is
similar to "include" except that it loads a dynamic object. The object
name can optionally have a function associated with it (currently in
parens, like:
load myplugin.so(init_myplugin)
) which, if given, will be invoked when the object is loaded. If no
name is given, there's a default symbol name which is invoked.
Multiple objects can be loaded in one statement.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
