[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: %.mk: %.m
would do the trick, I think.
OTOH, I'd still want to be able to create these checkers within the makefile
itself.
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).
Noel
- Re: non-recursive build question, (continued)
- Re: non-recursive build question, Noel Yap, 2004/04/28
- Re: non-recursive build question, Paul D. Smith, 2004/04/29
- Re: non-recursive build question, Noel Yap, 2004/04/29
- Re: non-recursive build question, Paul D. Smith, 2004/04/29
- Re: non-recursive build question, Noel Yap, 2004/04/29
- Re: non-recursive build question, Paul D. Smith, 2004/04/29
- Re: non-recursive build question, Sandy Currier, 2004/04/30
- Re: non-recursive build question, Noel Yap, 2004/04/29
- Re: non-recursive build question, David Boyce, 2004/04/30
- Re: pluggable out-of-date (Was: non-recursive build question), Noel Yap, 2004/04/30
- Message not available
- Re: pluggable out-of-date (Was: non-recursive build question),
Noel Yap <=
- Re: non-recursive build question, Boris Kolpackov, 2004/04/29
- Re: non-recursive build question, Paul D. Smith, 2004/04/29
- Re: non-recursive build question, Boris Kolpackov, 2004/04/29
- Re: non-recursive build question, sandy currier, 2004/04/28
- Re: non-recursive build question, Noel Yap, 2004/04/28
- Re: non-recursive build question, Paul D. Smith, 2004/04/29
Re: non-recursive build question, Noel Yap, 2004/04/28
Re: non-recursive build question, Noel Yap, 2004/04/28