Modular configuration

Stephan Kulow coolo at kde.org
Mon Oct 17 14:10:16 CEST 2005


Am Montag, 17. Oktober 2005 12:22 schrieb David Faure:
> I think that this can't be done from SConscript files, since calling
> env.Configure() from there barfs with "can't be done from builders", and I
> guess that makes sense; we need to do all the configure stuff before any of
> the building stuff. That's why I'm thinking of separate files, but maybe
> that's wrong and the reading of SConscript happens early enough that we
> could record 'configure needs' from SConscript files?
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.

So SConscript files are per se a bad place to put them. The name SconfNeeds is 
pretty bad too, but different topic.

>
> If not (i.e. if we need separate SConfNeeds files), can we reuse whichever
> mechanism scons uses to recurse into subdirectories to find the SConscript
> files, or even plug into that mechanism? Or should we just do the recursive
> find from SConstruct ourselves?
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. So I think a series of env.CheckCHeader("sys/param.h") calls is
asking for too much - especially if you can easily combine it with a ...s as 
done in autoconf, which does the loop for you. But with python not even this
is necessary.

So there are two issues here: a) how to find the files from subdirs and b) 
what to put in them - especially related to different architectures. But I 
guess, a well placed "if env['WINDOWS']" in a configure file serves us much 
better than having to dup everything. But we can include in the recursive 
lookup a way to look for _<PLATFORM> files additionally, so we can have both.

Greetings, Stephan



More information about the Kde-buildsystem mailing list