[Top][All Lists]

[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: Eric Melski
Subject: Re: Patch to allow make to load plugins that add new functions.
Date: Tue, 10 Apr 2012 11:18:38 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110922 Thunderbird/3.1.15

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
Electric Cloud, Inc.

reply via email to

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