On Tuesday 16 December 2008, David Faure wrote: > On Monday 15 December 2008, Alexander Neundorf wrote: > > 2.) You are probably using symbols from some library which you don't > > link to directly, but which was dragged in via one of the other libraries > > you link to, and these "dragged in" libraries have now been mostly > > removed. In this case, add these missing libraries explicitely to the > > TARGET_LINK_LIBRARIES() command. > > (because: less dependencies for packages, faster startup, some advantages > > in keeping binary compatiblity). > > Doesn't this break SC, i.e. people upgrading to a newer kdelibs (e.g. via > their distro) will suddenly be unable to compile 3rd party kde apps > released before KDE 4.2? > > Would it help to only enable explicitely in every module that supports it, > while leaving it disabled when compiling ksomeapp?
We had that since, I don't remember exactly, 2 months or so. If the "average" developer doesn't enable it (why should he), he may break the build for the ones who enable it. So, I know, it's not nice, but I think now is the time that it has to be forced on everybody :-/ I did my best to make sure everything links, but I alone can't get it 100% right. > Or does it break both SC and BC anyway, in which case this wouldn't even > help (e.g. ksomeapp can't link anymore, or 3rd party plasma applets will > stop loading...)? > > We _have_ to provide some stability in the build system... breaking SC > and/or BC is really not going in the right direction. I know, I know, and I fully agree. I raised this issue back in May or so, but even Dirk said it would be more important to do that now. Anyway, we don't really have a choice. The distributions are already shipping patched versions which do this (at least Debian), and Rex (RedHat/Fedora), Dirk (SUSE) and I think also a Gentoo packager said they would use these patches too. So even if we would not do this now, these major distros would do it anyway :-/ So, better we do it now, and at least the distros ship something we know. Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
