Modular configuration

[David Faure]

On Monday 17 October 2005 14:10, Stephan Kulow wrote:
> The main reason why you can't do this from SConscript files is that they work
> on an environment and configure's main task is to create that environment.
OK.

> So SConscript files are per se a bad place to put them. The name SconfNeeds is 
> pretty bad too, but different topic.
Hey, at least I didn't name it "unserconf" :-)
But I agree. Initially I called it needs because I only wanted "sys/stat.h, getmntent"
in it. But then I realized we want to categorize that, so it would be a python script,
not just a text file. So... SConf? SConsConf?
Actually I don't understand the "SConscript" name (the 's' belongs to both
"scons" and "script"?)

> I very much think we need something more easy to plug together, yes. And a 
> recursive search is pretty easy to implement and if you have to stat the dirs 
> pretty soon anyway, it isn't even very expensive at runtime. So I wouldn't 
> worry about plugging it somewhere. I don't think there is any reason to mimik
> the "obj = " syntax. As we simply don't create objects there, but want checks 
> to be done. 
OK.

> So I think a series of env.CheckCHeader("sys/param.h") calls is 
> asking for too much

What do you mean, it's asking for too much? Did rather you mean it would be OK to do that there?
I would agree, but it doesn't do the whole job, does it? E.g. it handles config.h but
it doesn't do the caching.

About the config.h output, we would need to put context.headerfile="config-lowlevel.h" 
somewhere, for all those subdir checks to go there. OK, config-subdirs.h, since it
might not only be about lowlevel stuff (?)

Or we might want per-subdir .h files (e.g. config-kdecore.h and config-kdeui.h), so that
it's easier to move a subdir to another module... but then we have to run the same tests 
more than once, if both kdecore and kdeui need sys/stat.h. Although, with the caching
it would be fast, just a bit strange on stdout.

Ah, and maybe it's enough to have CheckCHeader() calls if we handled
the caching like: automatically writing into CACHEDIR+'config-kdecore.py' 
that KDECORE_ISCONFIGURED=1, and not using kdecore/SConfChecks (new name :)
when that is set. If someone modifies that file, he needs to do "./scons configure"
after that, which is quite OK. This is getting somewhere - if we do the
per-subdir "ok, this is configured" caching automatically, then indeed
env.CheckCHeader("sys/param.h") from SConfChecks is enough.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).