On Sunday 30 April 2006 17:29, David Faure wrote: > On Sunday 30 April 2006 15:13, Alexander Neundorf wrote: > > 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.
Well, also modular, only different ;-) > 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. Hmm, not sure I understand. E.g. there are some tests which are only used in some ioslaves. E.g. HAVE_SENDFILE is used only in the file ioslave. Should this stay in kdelibs/config.h, or be moved to kdelibs/kioslave/config-kioslave.h or to kdelibs/kioslave/file/config-fileioslave.h ? This would be the most local location. When programming, making stuff as local as possible is usually considered a good thing. For the author of the file-ioslave (oops, isn't this you ?) it would probably be the most natural thing to add this check to kdelibs/kioslaves/file/CMakeLists.txt and create a config-fileioslave.h Or let's take the fish ioslave. It would be nice if I could simply copy kdebase/kioslave/fish/ somewhere and release it separately (with minor changes). For this purpose it would be nice if all configure checks the fish ioslave needs would be located in kdebase/kioslave/fish/. This will also be true for other applications (e.g. kwin styles, maybe also khtml, kolorpaint, well, apps for which it makes sense to be released separately). For these cases ideally all checks they need would have to be located in the specific subdirectory. But maybe this would lead to new problems, many config headers in every module, maybe multiple tests for the same thing done slightly differently, maybe with the same name or maybe with a different name, which might make debugging it harder. I'm not sure what the best way is. I think if application kbar needs a check, the check should be added in the directory of application kbar. And I think if we have separate header files (config.h, config-mount.h), we should also have separate configure files (ConfigureChecks.cmake, ConfigureChecksMount.cmake). Now concrete to kdelibs: There are a bunch of checks which are only used libltdl. If we create a config-libltdl.h, we need to modify the sources of libltdl. AFAIK libltdl is our own copy of the main version of libltdl. Is it ok to modify the sources or do we want to keep the changes there minimal ? What about kdecore/malloc/ ? is this still used ? Are modifications ok ? kdelibs/kjs: shall I add all the tests to kdelibs/kjs/global.h ? I would then prefer renaming kjs/global.h to config-kjs.h. Is Apple somehow involved here ? Bye Alex -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de Home: neundorf AT kde.org - http://www.kde.org alex AT neundorf.net - http://www.neundorf.net _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
