bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch to allow make to load plugins that add new functions.


From: Paul Smith
Subject: Re: Patch to allow make to load plugins that add new functions.
Date: Thu, 5 Apr 2012 20:16:24 -0400

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]