On Saturday 29 April 2006 00:24, Alexander Neundorf wrote: > SVN commit 535237 by neundorf: > > -check where some of the results are used > it seems there are quite a lot of checks which aren't used anywhere > I moved the (seemingly) unused checks at the of the file, I guess they can be > removed.
Right. E.g. HAVE_PUTENV makes little sense; putenv is our fallback in fakes.c in case setenv isn't available, but if neither of those are available then this must be a very strange platform indeed - and one we can't support anyway. If those HAVE_FOO are unused, just remove them. > Do we want modular configuration ? Yes... but maybe only up to a point. All those system header files (sys/types.h etc.) are very unlikely to change on a given system, so I'm fine with those remaining in some kind of global .h file, except that maybe we should rename it (config-lowlevel.h to reuse a name introduced by bksys?) to avoid people adding non-lowlevel things to it... Dunno. See, you can install FAM or CUPS on an existing system, so it makes sense to have this in separate .h files. But you can't really install sys/select.h or mkstemp on an existing system out of the blue... > Then we should create a kjs-config.h, a kioslave-config.h, a kdecore-config.h > and a kio-config.h I think. Not necessarily this way. The kdecore/kio split is kind of arbitrary and going to change and unrelated to configuration. Better have it split out by functionality instead, like I did with config-kdirwatch.h or config-cups.h etc. (Can we stick to config-foo.h instead of foo-config.h, since that's what I started using everywhere? ;) All the mntent/fstab/mnttab/"sys/mount" stuff (i.e. everything that you found as "kio, kdecore") is only due to a kind of API duplication from kde3 (KMountPoint vs the functions in kio/global.h), and Josef Wenniger told me he was working on merging that. Meanwhile and independently from this, we can move all those defines into a config-mount.h or config-kmountpoint.h and use them from both places right now, and in the end only KMountPoint will use that stuff. The benefits of modularity ;) Real modularity (based on functionality, not on library split). -- 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
