Howto fix KDE4 Buildsystem with CMake CVS

[Alexander Neundorf]

On Monday 28 January 2008, Brad King wrote:
> Andreas Pakulat wrote:
> > On 28.01.08 16:04:06, David Faure wrote:
> >> On Monday 28 January 2008, Andreas Pakulat wrote:
> >>> Opinions? Better Ideas?
> >>
> >> Does replacing -lsolid with ${KDE4_SOLID_LIBS} work?
> >> After all we already have those variables, so we can avoid -lfoo
> >> completely I think.
> >
> > Its not quite that easy. The thing is that -lsolid is produced my
> > cmake's export_library_dependencies() function. So we'd have to find all
> > uses of all KDE_XXX_LIBS variables that include -lsolid and then add
> > KDE_SOLID_LIBS to the target_link_libraries() call.
> >
> > And then again if compiling aborts with -lkparts or some other lib.
>
> It looks like export_library_dependencies is misused a bit.  The command

Yes, but I noticed that quite late (you showed me the intended way to use it I 
think august last year) and at that time the KDE developers were already used 
to using these variables, so I didn't change it anymore.

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

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 just noticed that export_library_deps() doesn't respect the OUTPUT_NAME 
property of a library, exporting the full install location would also fix 
this problem:

add_library(foo foo.c)
set_target_property(foo PROPERTIES OUTPUT_NAME notfoo)
add_library(bar bar.c)
target_link_libraries(bar foo)
export_library_dependencies(deps.cmake)

will have "foo" in it, although no libfoo.so will exist, so a project which 
uses that file will not work.

Can you have a look at that ? 
I can try to come up with a patch, but you can fix this much faster.
If you want I can create a bug report for the OUTPUT_NAME bug.

Alex