Howto fix KDE4 Buildsystem with CMake CVS
brad.king at kitware.com
Sun Feb 17 16:28:14 CET 2008
Alexander Neundorf wrote:
> There is still the problem with OUTPUT_NAME which is a real bug.
We can fix that in 2.6, but without another patch release to 2.4 that
gets put in all the major distros you won't be able to depend on the fix
anyway. You should probably use OUTPUT_NAME only on an executable
target to give it the same name as a library. Then the library can
export with the correct name.
>> How was this all working with 2.4? Do the effects of
>> CMAKE_LINK_OLD_PATHS completely solve the problem with 2.6? If so, that
> Actually I'd like to use the new style, since this will avoid the problems it
> is supposed to avoid :-)
Whether CMAKE_LINK_OLD_PATHS is defined or not the full paths to known
libraries are still given to the linker. The option only enables
passing of their locations in -L paths for no reason but compatibility
with projects that don't call LINK_DIRECTORIES properly. Don't let me
talk you out of doing it the right way though :)
> What do you think about putting
> into the installed file from kdelibs ?
This sounds fine. Then when you switch to the new-style export in the
future your user projects won't have a bunch of extra link_directories
calls in them. What we've done for Kitware projects is have the config
file loaded after find_package has found the project just specify
everything in variables. One variable contains the name of a "use file"
that actually runs commands that affect the build (like link_directories
and include_directories). I don't see much of a problem with putting
the link_directories call directly in the code loaded by find_package to
avoid requiring extra code in user projects to load use files. I
suggest putting such code inside if conditions so users can block them
> I could do this. How are the directories added via LINK_DIRECTORIES() handled
> when determining the order of the directories, which should still be required
> e.g. for the rpath ?
The extra directories are included in the link directory set for
ordering along with the directories containing libraries known by full
path. A single ordering is computed for both -L paths and the RPATH
using the linkable library names.
Ordering of directories is no longer done for -L paths since all
libraries whose full paths are known are passed directly as file paths
(and those for which the full path is not known cannot participate in
ordering). Ordering for RPATH computation works by taking the set of
known full paths to shared libraries by their *soname* and constructing
a safe order among all paths (both those containing libs and those
listed in link_directories). This should resolve problems like the one
last year with having to install a qt3-dev package just to get RPATH
ordering correct. It also means you can have as many extra link
directories as you want without affecting runtime loading of libraries
with known full path. The order of directories is preserved as much as
possible subject to constraints from known libraries.
More information about the Kde-buildsystem