thiago at kde.org
Tue Oct 18 02:33:29 CEST 2005
David Faure wrote:
>> 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" :-)
Call it SConfigure then. Simple, effective :-)
>> 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.
It can store the result of the check somewhere in the env object and write
the config-*.h file when the SConfigure script ends.
>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 (?)
Can't it simply concatenate the various subdirectories.
For instance, any test done inside kdecore/network/SConfigure would end up
In fact, I'd go as far as have one include per test, so that we can do:
And config/kdecore.h would in turn be just a bunch of #includes to the
individual tests performed in kdecore/SConfigure.
>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.
No, if you run the same test twice, it should use the cached value
Tests should minimise the side-effects they create. For instance,
autoconf's AC_CHECK_HEADERS add each successful header to the list of
includes; AC_CHECK_LIBS adds each successful lib to LIBS. We may want to
avoid doing that, so that tests are __attribute__((pure)) or, even
Here's my take on the subject of modular configuration:
1) The top-level SConstruct or an auxiliary script gets called by the user
2) It builds a list of subdirs containing SConfigure scripts;
3) It initialises the test environment and performs the global checks;
4) For each SConfigure script found, it runs its body;
5) [tell me if this is possible] For each SConfigure script found, it runs
the "bottom" or "end" function, if defined;
6) It parses the test result structure and dumps it to a file (call it
"config.status"), writes the .h headers into config/ and a .py script to
be loaded by the build (or the build could load the result dump);
In order to have per-dir #includes, the individual tests (or the
equivalent of AC_DEFINE) should also record the directory it was called
from (the top-level SConstruct saves the dir name to a variable before
running the body).
If #5 isn't possible, we can define an atexit()-like function, for stuff
that should be run when the script finishes. As I expect most of that to
be in the form of messages like "libXau not found, so kdm will not be
build", we can provide a convenience function for that. In fact, come to
think of it, this sounds preferrable.
I have also some ideas for the tests themselves, but this email will get
lengthy if I start it now. I'll start another thread once we settle on
the modular configuration. But we have to remember that we have some very
complex tests, which may involve running programs and parsing its output.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
2. Tó cennan his weorc gearu, ymbe se circolwyrde, wearð se cægbord and se
leohtspeccabord, and þa mýs cómon lator. On þone dæg, he hine reste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20051018/54fbee74/attachment.pgp
More information about the Kde-buildsystem