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

[Eric Melski]

On 04/05/2012 11:59 PM, Tim Murphy wrote:

> As for other tools like Electric Make, I want to be able to arm-twist
> them to support plugins (politely of course, Eric :-) ) without them
> being able to say it's "impossible" or unreliable or that it requires
> them to simulate the volatile internals of make to some infeasible
> degree.  I realise that this is just my interest but it makes the
> difference between bothering to use a plugin mechanism and not
> bothering at all since it couldn't offer me a uniform makefile that I
> could use across systems - I'd solve all my worries on GNU make and
> still be busted on emake and since GNU make doesn't offer that amazing
> filesystem which tells you when you have parallelsim problems and
> corrects them. In other words I can't give up on emake without
> converting 100s of developers into experts in writing good parallel
> makefiles and inventing a way to get make to work on clusters of
> machines (without pvmgmake's horrendously complicated setup).   People
> are so much more difficult than software.
>
> So my vote, FWIW, is to define what one does expect make to offer
> plugins (the "nice" bits of make) and define what it definitely
> doesn't and won't in the near future.  Anyone who wants a lot more is
> probably going to have to customise make itself anyhow.  I think the
> plugin should say what "environment" it expects and make should decide
> if it can offer that.  If make fails on something it claims to support
> then it's a bug on make otherwise it's clearly a plugin problem etc.
>
> As you say with expectations, one has to set them at some point.

Adding a plugin mechanism to ElectricMake has been on my wishlist for 
quite some time actually.  I'd love to collaborate with Paul, et al, on 
the design so that we come up with something that works for both gmake 
and emake.  In my wildest imaginings we could cook up something that 
would be binary-compatible, so we only have to compile a plugin once to 
use it with both tools, but I doubt that's really achievable.  The next 
best thing would be source-compatibility, so we at least don't have to 
tweak the plugin implementation to work with each tool (although I 
suppose that too could be manageable, in the same way that you see 
plugins for scripting languages with different 'bindings' for different 
languages -- still, we would need to agree on some fundamentals for that 
to work I think).

The single biggest issue in this regard is a difference in architecture 
between gmake and emake.  Fundamentally, gmake is one-make-per-process, 
and there are a lot of assumptions and shortcuts baked into the code 
because of that.  emake is many-makes-per-process.  In practical terms 
that means that we have to pass around additional context when doing 
expansions (eg, you have to know which make instance the expansion is 
part of, so that you use the right variable table).  I think to make 
something that would work for both gmake and emake we would have to 
abstract away this difference -- for example, rather than directly 
accessing data structures, we would define a set of API's for the 
various operations that are needed during expansion.

So there's definitely interest in collaboration on our end; is there any 
interest from the gmake devs?

Best regards,

Eric Melski
Architect
Electric Cloud, Inc.