Howto fix KDE4 Buildsystem with CMake CVS

[Brad King]

Alexander Neundorf wrote:
> On Monday 28 January 2008, Brad King wrote:
>> It is up to the project that calls export_library_dependencies to
>> produce a variable containing the link directory.  The user project
>> should be able to do
>>
>>    find_package(XXX REQUIRED)
>>    link_directories(${XXX_LIBRARY_DIRS})
>>    target_link_libraries(myexe zot)
> 
> Getting all the lib dirs to CMAKE_SOURCE_DIR/CMakeLists.txt, where 
> export_library_dependencies() is called has two problems:
> -everybody who uses not the project-default install dir has to remember that 
> he has to do something so that his dir also ends up in the installed file
> -getting information from some subdir to the parent dir is hard (easier with 
> 2.6)

Kitware projects have done it this way for years.  Instead of trying to 
send information from the subdirs to the top we send it the other way. 
The top directories configure the install locations and tell the child 
dirs where to install.  Then the locations are placed in the config file 
to be loaded by user projects.  It is a bit of work for the developer, 
but that is how we did it and how the export_library_dependencies 
command was meant to be used.

CMake 2.6 provides a much better alternative as discussed below.

> I think having export_library_dependencies() really export the install 
> location of the libraries would be a good thing (in the 2.6 part of the 
> created file).

I don't think changing 2.6's export_library_dependencies command to use 
full paths is the solution.  It would only be redundant work for a 
command I don't want people to use anymore (see below).  The command 
does not have access to the install locations of targets.  The content 
it produces was meant for use both from build trees and from install 
trees.  Changing it to use full install paths would break projects 
depending on that capability (VTK, ITK, vxl, and ParaView at least). 
Besides, how would someone using 2.6 to build their project deal with 
kdelibs built and installed by 2.4?  The paths would not be available.

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 
means that some of the libraries were getting found and linked using 
full paths.  Otherwise the -L paths would not have been there before. 
How are the full paths to some libraries getting passed to the user?

CMake 2.6 will provide full support for executables and libraries with 
that install(EXPORT)/IMPORTED-target feature we designed last summer. 
It is already working and tested in CMake HEAD.

I think the solution is to start using the new export/import feature 
when 2.6 is released.  As long as both the exporter and importer are 
using 2.6 it will work well.  If both are using 2.4 then the current 
stuff can be used and will work as it does now.  If the exporting 
project is built with 2.6 and the importing project with 2.4 the current 
approach should also continue to work.  What remains is to try to 
support exporting with 2.4 and importing with 2.6.  For that case we 
could just define CMAKE_LINK_OLD_PATHS in the old-style export.

Once this dual scheme is setup then you can start building pre-compiled 
distributions with 2.6.  Setup the installed config files to load the 
new-style exports when the user uses 2.6 and the old-style exports when 
the user uses 2.4.  Then tell anyone that has too many problems with the 
old-style exports to start using 2.6.  Eventually when you drop support 
for 2.4 you can just get rid of the old-style exports altogether.

-Brad