On Sunday 30 April 2006 22:27, Alexander Neundorf wrote: > 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. I agree.
> For the author of the file-ioslave (oops, isn't this you ?) Not really, coolo is the main author iirc. Doesn't matter :) > 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/. Sure. But this is only the case of a small subdir. The file ioslave is one small and indivisible module, and this can't be compared to the case of kdecore or kio, where things are likely to move out or be reorganized otherwise. > 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). Right. > 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. Right. This is what we have those FindFoo.cmake modules to centralize that code, isn't it? Well, not everything happens there though, maybe we want to turn more things into FindFoo-type modules. > 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. But if it's about checking whether sys/types.h is present, then it seems pretty redundant to do it everywhere. But well most kde apps shouldn't use system stuff.... but right now they do. > 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). I don't see the point in putting a few lines here and there instead of all in CMakeLists.txt See the kdelibs/kjs/CMakeLists.txt extract that Ralf just posted. It's all there, instead of moving the if/set/else/set/endif (or your macro) to ConfigureChecksPcre.cmake (and this would be the only line there!!) We need to put together what belongs together, not split out the code unnecessarily. > 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 ? I don't think this matters much anymore. Rumours are that kde4 might even get rid of libltdl. Meanwhile I don't see a problem with modifying it. > What about kdecore/malloc/ ? is this still used ? Are modifications ok ? Ask Seli, but same there, I don't see a problem with changing its use of config.h > kdelibs/kjs: shall I add all the tests to kdelibs/kjs/global.h ? Might make sense, especially if kjs gets split out of kdelibs at some point... > I would then prefer renaming kjs/global.h to config-kjs.h. Is Apple somehow > involved here ? Yes; basically global.h.cmake is ours so we can modify it, but if we rename it then we are introducing a useless difference in all the other files. Let's not do that. -- 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
