Modular configuration

[Thiago Macieira]

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 $(top_builddir)/config/kdecore-network.h

In fact, I'd go as far as have one include per test, so that we can do:
	#include "config/have_sys_param_h.h"

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 
automatically.

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 
better, __attribute__((const)).

Here's my take on the subject of modular configuration:

1) The top-level SConstruct or an auxiliary script gets called by the user 
running "./configure";

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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20051018/54fbee74/attachment.pgp