Reducing excess linkage - cmake 2.6 IMPORTED targets and LINK_INTERFACE_LIBRARIES for kdelibs

[Alexander Neundorf]

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 <some_identifier> 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