modular configuration(Re: KDE/kdelibs)

[David Faure]

On Sunday 30 April 2006 15:13, Alexander Neundorf wrote:
> The lowlevel in bksys meant checks for lowlevel stuff ?

Yes - all the system-level stuff (includes and functions), which is basically what's left in ConfigureChecks.cmake
except for a few things.

> Yes, these are the two options: 
> -splitting it on functionality (like with config-acl.h)
> or
> -splitting it by library
> 
> Both make sense.
> To me it seems more natural to split by library. If you need a check in kfoo, 
> just add that check in kfoo and put the result in config-kfoo.h. This would 
> also make it easier to move directories around or to compile parts 
> independent from the rest of the module, since it will contain all the 
> configure checks it needs.

I agree, but with kfoo being a functionality (e.g. acl) or a functionality-specific class (e.g. kdirwatch or kmountpoint), not a whole lib.
If you move KMountPoint from kdecore to kio or vice-versa, nothing changes in the config-mount.h file.
Whereas if it's all mixed up inside config-kio.h then we're back to the initial problem: not enough modularity.

But I agree with you about the lowlevel stuff (from libc, so unlikely to change) used in N subdirs.
For that part we can either keep one config.h or go for config-kdecore.h / config-kio.h / ...
to minimize recompiles when a new HAVE_FOO check is needed for a library.
I'm fine with a per-lib split, but ONLY when a per-functionality split isn't possible or doesn't make 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).