[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: Noel Yap
Subject: Re: pluggable out-of-date (Was: non-recursive build question)
Date: Fri, 30 Apr 2004 09:55:12 -0400
User-agent: Mozilla Thunderbird 0.5 (Windows/20040212)

David Boyce wrote:

At 07:31 AM 4/30/2004, Noel Yap wrote:
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.

A special target, something like (but probably with a better syntax):

.UP_TO_DATE_CHECK: checker: %.m

would do the trick, I think.

OTOH, I'd still want to be able to create these checkers within the makefile 

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.

The one I personally experienced was with gcc-2.96. It's so bad that a patch is infeasible. The fix is to upgrade to 3.2 although I've seen problems with this, too, but I didn't get a chance to create a minimal test for it so these problems may not be insurmountable.

The problems I've seen were with C++ code. C linking/loading is probably way more stable. Since GNU make is written in C, the problems with dynamically loading libraries shouldn't strike them from consideration although, personally, I would still prefer coding the checkers directly in the makefile (which includes shelling out and calling an executable).


reply via email to

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