Howto fix KDE4 Buildsystem with CMake CVS

[Brad King]

Alexander Neundorf wrote:
> On Sunday 17 February 2008, Brad King wrote:
>> 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. 
> 
> I just tried that and still got:
> 
> Linking C executable hello
> /opt/cmake-HEAD/bin/cmake -E cmake_link_script 
> CMakeFiles/hello.dir/link.txt --verbose=1
> /usr/bin/gcc    -fPIC "CMakeFiles/hello.dir/main.o"  -o hello -rdynamic 
> libfoo.so /opt/test2/lib/libkdefx.so -Wl,-rpath,/home/alex/src/tests/rpathtest/b2:/opt/test2/lib
> 
> Shouldn't there be -L/opt/test2/lib/ included ?
> 
> I have set both variables:
> set(CMAKE_LINK_OLD_PATHS TRUE)
> set(CMAKE_BACKWARDS_COMPATIBILITY 2.4)
> 
> Am I missing something ?

The -L options are added only if there are some -lfoo options. 
Otherwise they are useless anyway.

-Brad