[Top][All Lists]

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

Re: pluggable out-of-date (Was: non-recursive build question)

From: David Boyce
Subject: Re: pluggable out-of-date (Was: non-recursive build question)
Date: Fri, 30 Apr 2004 09:36:12 -0400

At 07:31 AM 4/30/2004, Noel Yap wrote:
There's a few of issues with this solution:
- it's conceivable that out-of-date calculations may want to be done on a per-rule basis - even if it's on a per-project basis, a per-make calculator is still too course-grained

I'm not sure we're talking about the same thing ... what do you mean by a per-make calculator? If you mean you'd like the option of using different strategies for different rules or classes of targets, I could see that being useful in some cases. But the whole idea would be to make the signature of the discriminator rich enough (i.e. pass it enough data) that it can implement this kind of logic internally. It would have to have access to the data structures continaining lists of prereqs and targets, plus the build script, so it could easily be designed to use CRC32 for some classes of files and date stamps for others for instance. If you wanted to be that complicated.

Or, since clearmake seems to be our pole star on this, consider that it uses various special targets (e.g. .NO_DO_FOR_SIBLING, .NO_CONFIG_REC, etc) to handle such fine-tuning. So I guess an alternate plugin style would be a special target which tells make what discriminator to dlopen and use for what targets. I'm sure there are other and probably better interfaces as well.

My main point is simply that a dlopen-ed discriminator function might be the most open, and least intrusive, architecture. And that dlopen (and the equivalent Win32 API which I think is called LoadLibrary) is what underlies most classic plugin implementations in browsers, Apache, etc.

- I've seen some really nasty problems with Linux's loader

Hmm. I haven't. Or more specifically I've often run into linker/loader issues but they've generally turned out to be because this stuff can be really complicated and I hadn't fully read or understood the manual, not because of an actual bug. Are you saying there are actual crippling bugs in the GNU/Linux loader (and what version?) or just that the arcana of working with it might be too painful for general use? If so I'd counter by saying that there are many quite robust technologies (Apache comes to mind) which use this same technique and which run fine on Linux from time immemorial.

Having said this, I do agree that a pluggable interface is the way to go. I don't know GUILE (yet) but I'm hoping GUILE support along with a GNU make hook will allow this feature.

I know, if possible, less than you do - only that Guile is some kind of scripting language designed to be built into software tools a la TCL, and that such integration is in the long-term plan for GNU make. If it offers some help in a plugin implementation I guess that would be great. I can't help feeling that integrating a full and not well-known scripting language into the already arcane and idiosyncratic GNU make syntax threatens to reduce the already small number of people who truly understand it to a handful. But that's a different thread and probably one that came and went before I was here.


reply via email to

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