KDE/kdelibs
Sune Vuorela
debian at pusling.com
Sat May 9 12:44:50 CEST 2009
On Wednesday 06 May 2009 23:12:35 Alexander Neundorf wrote:
> 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:kde-buildsystem at kde.org
> >
> >
> > 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) ?
I don't think find_package(KDE4) should find anything but "real kdelibs", and as
the experimental parts are packaged seperately, it neeeds two checks.
I'm not that interested in making it possible to install the experimental
parts in a different destination.
I would though really prefer if the experimental libs were all seperate, so
you did find_package(libfooexperimental) if you needed the functionalities of
foo
/Sune
> 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
> Kde-buildsystem at kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
--
I'm not able to log from a mouse from ICQ 5.3, how does it work?
You neither need to insert on the desktop, nor should get access on a tower of
the back-end of a digital DVD pin for overclocking the RAM computer.
More information about the Kde-buildsystem
mailing list