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've seen some really nasty problems with Linux's loader
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.
Noel
David Boyce wrote:
It's always struck me that the best way to answer the out-of-date question generically is via a "plugin" design. Any implementation that's hardwired into make is bound to be wrong for someone's needs. Couldn't make do something like this: at startup, it uses the dlopen/dlsym() interface (there's something similar on Windows) to look for a function with a particular name and a documented signature including a boolean return value. If found, that's what it uses to make subsequent out-of-date decisions. If not (the normal case), it falls back to an internal function which simply implements the forward-timestamp-based logic that's always been standard.
This would allow for alternate implementations of statefulness, entirely configurable by the client site. Developers would only need create a shared library implementing the documented function. They could then build gmake so as to link it in explicitly, or LD_PRELOAD it on an as-needed basis. I could see a whole cottage industry of plugins developing.
One limitation is that GNU make has probably been ported to some old platforms which don't have dlopen/dlsym or similar. But IMHO it wouldn't be so bad to make this feature depend on a HAVE_DLFCN_H configure macro and thus be available only on modern platforms, which all support something similar AFAIK. Certainly SUS specifies dlopen.
Would this work or am I misunderstanding something about dlopen?
-dsb
_______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
