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

[David Boyce]

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.

-dsb