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, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
