From kde-buildsystem Fri May 09 22:34:18 2008 From: Alexander Neundorf Date: Fri, 09 May 2008 22:34:18 +0000 To: kde-buildsystem Subject: Re: Reducing excess linkage - cmake 2.6 IMPORTED targets and Message-Id: <200805100034.18605.neundorf () kde ! org> X-MARC-Message: https://marc.info/?l=kde-buildsystem&m=121037221113037 On Tuesday 06 May 2008, Dirk Mueller wrote: > On Monday 28 April 2008, Alexander Neundorf wrote: > > -cmake 2.6.0 is not released yet and we are already at alpha1 stage of > > KDE 4.1 -the patches kind-of break source compatibility > > not really.. apps that break due to that are invalid anyway. for every 3rd > party module which we depend on and that switches away from libtool we run > into the same issue (e.g. libvorbis just recently pops up my mind). And > then again, binary compatibiliy is what counts - not source compatibility. Why doesn't source compatiblity count ? > and binary compatibility is not broken, as long as the app links all that > it needs directly by itself. > > > , stuff which links with > > KDE 4.0.x may not link anymore once this patch is applied > > thats the reason why the patch should be applied to be able to optionally > use this feature as soon as possible, so that those who care (I count > debian and opensuse packagers here) can iron out all the quirks and fix all Would the official SUSE packages be built with this patch enabled or disabled ? > the failing packages before users stumble over it. I could add it to the > dashboard so that we can see the failures right away. > > > Depending on how we deal with the compatibility problem, I'd like to do > > this once trunk is open for KDE 4.2 and require cmake 2.6.x by then, so > > *every* developer will notice when something breaks. Then we'll also have > > time to make sure at least the sources in KDE svn build properly. > > Thats one solution - another solution is to make it optinally available > now, so that distributions can fix the migration path, and make it a > requirement with KDE 4.2 (or maybe even 4.1). > I forgot to add: Alex do you object to it being available optionally > already now? I don't feel able to support two different link styles for KDE 4.1. Enabling this means: Adding EXPORT for all installed libraries. This could be done by extending INSTALL_TARGETS_DEFAULT_ARGS. Or by adding it directly to the install() commands, which would have IMO the advantage that the developers see what's happening (but it's probably too late for that, since we added INSTALL_TARGETS_DEFAULT_ARGS). It also means setting the LINK_INTERFACE_LIBRARIES property for all installed libraries. Getting this right may take a some days, until it is working on all platforms again. http://techbase.kde.org/Schedules/KDE4/4.1_Release_Schedule says "hard feature freeze" and beta 1 May 20th. This is 10 days to go. So IMO without modifying the release schedule it is simply to late for this change now. I would really feel much more comfortable if we support only one link style. This would mean we would require cmake 2.6.x, i.e. 2.6.0 right now. If we would do this now, I want to have at least a 2 weeks warning period, which would be at least May 26th. Right now we are in the situation that cmake as it ships with all distros since last year is recent enough for KDE 4. If we require 2.6.0 now there will be no distro which ships with this now. There may be some distros which have it already available for updating. It is also still unclear whether there may be some bugs left in 2.6.0 for building KDE on all platforms. If we require 2.6.0 now, we won't have time to require e.g. a fixed 2.6.1 in time for 2.4.1. So: I'm all for doing this for KDE 4.2 I'm against requiring cmake 2.6.0 now I don't think I can handle the workload two link styles bring. Alex _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem