Hi, 2008 m. May 20 d., Tuesday, Alexander Neundorf rašė: > What would you think about installing a KDELibsDependencies.cmake with > different contents ? > This could be done either by: > -postprocessing the file created from kdelibs by the distros > or by I don't quite understand what you want to gain by postprocessing. It looks way more hackish than doing it the proper cmake 2.6.
> -creating a different file in kdelibs (problem may be the different > debug/optimized versions of the libs, but then again, this should matter > only for windows, right ?) Well, that's not a bad idea. kdelibs and kdepimlibs can generate two dependency files with cmake 2.6: 1) Old with _LIB_DEPENDS. 2) New with IMPORTED targets and LINK_INTERFACE_LIBRARIES in effect. Then whichever to use could be chosen at build time of each KDE package with a standardised -D switch to cmake (e.g. -DUSE_LINK_INTERFACE=true). Distribution packages will pass the option to cmake to enable the new way whereas Joe Average will `cmake . && make && sudo make install' and the build process will use the old evil, but compatible way. Hence you get no bug reports about linking failures from inexperienced users, but distribution maintainers can still use the fixed build system. 1) People who are not interested won't use the feature and even won't notice that someting has changed (old way stays default even on the distro using the new way to build its official packages). 2) People who are interested will provide patches for KDE developers. We at Debian already have patched all official modules. We could sumbit patches now but we need an official macro which would not set LINK_INTERFACE_LIBRARIES on the target unless "the new way" is enabled. The point 2) from my initial mail is very important too. > This solution would have the advantage that it would give the same results > with cmake 2.4.x and 2.6.x, which would be a big advantage. Even if you do postprocessing, other developers will _still have to patch_ numerous target_link_libraries(), so why not specify link_interfaces_libraries (via some macro probably) at the same time? I don't think you should waste time and effort to solve excess linkage problems for cmake 2.4 users. All new distro releases will not include it anyway. The time should be better spent supporting a proper solution as an alternative to have it ready as default for KDE 4.2. -- Modestas Vainius <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
