On Thu, 2012-04-05 at 23:59 +0100, Tim Murphy wrote: > I see the value in a plugin system as being that I don't have to > recompile the plugins for every version of make. In a way it's tending > towards "why bother" if you did have to do that.
Well, this kind of combines with my other issue regarding automatic remaking of objects :-) The idea is that you wouldn't have a predefined set of make plugin OBJECTS that you distributed. Instead you'd keep the SOURCE CODE for your plugins for your build environment right there in your source tree, and build them as part of your build process. If they are automatically recompiled when out of date, this would be seamless. I have a hard time envisioning massive, complex plugins: most likely they'll be small, straightforward functions that perform targeted operations more efficiently than make (or Guile) can do them. Such things would only take a couple of seconds to build and would be unnoticeable in any serious build environment. > You also have to think about where in makes startup these things > happen. Some stuff needs to be done early, some later - if your plugin > loader needs a fully initialised make process (because it has to read > a makefile to do load) then although you might think it is infinitely > flexible, it does come with limits. Heh, I didn't say "infinitely flexible"; that's too much to ask. We have the --eval command line option already. I'm open to adding an environment variable if someone can describe a powerful use-case. > I have to admit to a secondary agenda in that I'm thinking about tools > like Electric Accelerator which mimic gnu make - I'd like them to be > able to implement plugins too so that my build system can be > accelerated ($$$$$) or free :-) depending on the users choice. This > is why I was thinking of it being quite defined and with restricted > access and using versions so that it's clear what needs to be > supported and what's offered. Hm. I'd need to understand better what exactly would be involved here. What kind of plugins would be used for this and what would they do? I'm not that jazzed about designing in a vacuum, especially just to enable proprietary software to work better with GNU make :-). What I really DON'T want to do is provide a locked down interface, which then turns out to be too restrictive to be useful and we're constantly fielding requests to open this or that, and having to worry about backward compatibility, etc. I'd prefer to leave things open, at least for a while until we get some feedback/experience. Yes, this does shift the burden away from me and onto the plugin writers (where it belongs of course!! ;-)), but it's not like there are so many versions of make floating around that this is that onerous. I was thinking of marking this feature as "experimental" in the first release (in the documentation), just to be more clear on expectations. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
