Howto fix KDE4 Buildsystem with CMake CVS

[Alexander Neundorf]

On Saturday 16 February 2008, you wrote:
> 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,

Basically we do the same, it's just that I can't guarantee that really all 
subdirectories use these default install locations.
You can't compare Kitware and KDE in this regard, KDE has hundreds of 
developers, many know only the basics of cmake, it has many many projects, 
both in KDE svn and outside KDE svn, at the same time KDE doesn't have more 
cmake-specialist man hours available than Kitware.
So the solution must be easy-to-use and very modular, and the cmake files must 
look clean, if possible without special casing e.g. for different cmake 
versions (if our buildfiles would be too complicated we would loose 
contributors).

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

Yes, I know and I would like to use it, but I can't.
To use it KDE would have to require the appropriate CMake version, and this 
won't happen before a non-beta version of CMake 2.6 is shipped by default by 
the major distributions. So maybe in late summer or fall this year.

> > 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).  

Yes, I know.

> The command does not have access to the install locations of targets.  

I think it could find out via the InstallTargetGenerators in cmMakefile.

> 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).

Oh, being usable from the build tree, I didn't think of this. This really 
excludes the possibility to use the install location.
Except with even more special handling, like detecting whether the file is in 
the build tree or installed and then doing different things :-/

There is still the problem with OUTPUT_NAME which is a real bug.

> 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

Actually I'd like to use the new style, since this will avoid the problems it 
is supposed to avoid :-)

What do you think about putting 
LINK_DIRECTORIES(${LIB_INSTALL_DIR})
into the installed file from kdelibs ?
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 ?

This would work for most cases, except those where some library is installed 
to some other directory. 

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

Example:
find_library(KDE4_KHTML_LIBRARY NAMES khtml PATHS ${KDE4_LIB_INSTALL_DIR}
                                NO_DEFAULT_PATH )
set(KDE4_KHTML_LIBS ${khtml_LIB_DEPENDS} ${KDE4_KHTML_LIBRARY} )

so the depending library always has the full path.

> 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

I can't, see above.

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

Yes, I'm looking forward to that day...

Alex