Howto fix KDE4 Buildsystem with CMake CVS

[Brad King]

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 
> LINK_DIRECTORIES(${LIB_INSTALL_DIR})
> 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 
if desired:

if(NOT KDE4_NO_AUTO_LINK_DIRECTORIES)
   link_directories(${KDE4_LIB_INSTALL_DIR})
endif(NOT KDE4_NO_AUTO_LINK_DIRECTORIES)

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

CMake 2.4:

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.

CMake 2.6:

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.

-Brad