On Wednesday 06 May 2009, Aaron J. Seigo wrote: > SVN commit 964099 by aseigo: > > builds with kdelibs, but -should- also be buildable separately. there's > still the issue of the FindLibKNotificationItem.cmake file outstanding, or > does that not matter now that it's in kdelibs/experimental/? build system > guidance desired. CCMAIL:[email protected] > > > M +1 -0 CMakeLists.txt > M +1 -1 experimental/knotificationitem/knotificationitemprivate_p.h > M +5 -4 > experimental/knotificationitem/test/knotificationitemtest.cpp
Ok, so now we have a modular build of kdelibs. What should be supported ? 1) Building and installing complete kdelibs in one go, and having everything available by just doing find_package(KDE4) ? 2) Building and installing kdelibs without experimental, then building and installing experimental to the same destination, then have everything available via find_package(KDE4) ? 3) As 2), but installing experimental/ to a different location ? I'd vote against this, since then we will have to define rules how to behave e.g. when kdelibs/ was built and installed completely, and additionally there is somewhere an extra experimental/ 4) As 3, but to have everything available, you have to do find_package(KDE4) find_package(KDE4LibsExperimental) Then it would be quite obvious that these are separate packages and that they could reside in separate locations. It would also mean that moving something from experimental to stable kdelibs would be a source incompatible change (since e.g. the variable names would change from KDE4LIBSEXPERIMENTAL_KNOTIFICATION_LIBRARY to KDE4_KNOTIFICATION_LIBRARY. I think supporting this option would also mean that 1) would _not_ be supported. I'll have time to do something this weekend. Including setting up nightly builds for kdelibs-all-in-one and separated. I'm for supporting options 1) and 2), then the optional parts of kdelibs can install e.g. a KDELibsExperimentalConfig.cmake file into the install directory of kdelibs itself, so FindKDe4Internal.cmake will know where to look for them, instead of starting to search for them, and hoping to find a good one. Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
