Modular configuration

[David Faure]

I have been thinking about how to address the problem of modular configuration.

The problem:
--------------
Assuming that lowlevel.py will be reused by other modules, I don't want
to add all the checks that we need for kdelibs in there.
(e.g. checking for getmntinfo, volmgt, dlfcn.h, sys/mntent.h ... all those
things being encapsulated by kdelibs classes, I don't see a need to check
for them in other modules than kdelibs)

I could write a kdelibs_lowlevel.py which would check for all those things,
but that's not modular. And we need a modular solution for other modules too,
if you remember the mess that happened when moving kmail from kdenetwork
to kdepim: the whole toplevel configure.in.in was copied over since nobody
knew which checks were really needed for kmail and which checks were not.

The high-level idea for a solution:
----------------------
I would like to be able to define "configure needs" in subdirs of a svn module,
i.e. to have a file under kdecore that says
"I need the headers sys/stat.h, sys/mntent.h, sys/param.h, paths.h, limits.h, execinfo.h etc.
and I need the c functions mmap, getmntinfo, setmntent, etc."
(later on we could then even automate the creation of that file by a script
that scans the source files for those headers and functions, but not at compile
time imho, just as an easy way to keep those files in sync).

The syntax could be like
confneeds.cfunctions += "mmap getmntinfo setmntent"
confneeds.cheaders += "sys/stat.h sys/mntent.h sys/param.h paths.h limits.h execinfo.h"
and somehow the toplevel SConstruct would concatenate all such (SConfNeeds?) files
and pass that information to one of the configuration modules.

(or a syntax like 
confneeds = env.confneeds(env)
and using '=' instead of '+='
This would be more consistent with obj = env.kdeobj()... but then we need
those different confneeds objects to somehow write their information into
the same common object, we don't need to check for sys/stat.h more than once...)

Implementation questions:
-------------
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?

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?

Anyway - do you think this idea makes sense?

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