kdebindings, generator, LD_LIBRARY_PATH

[Alexander Neundorf]

On Friday 30 October 2009, Yury G. Kudryashov wrote:
> Hi!
>
> The following lines in kdebindings/CMakeLists.txt do not solve the problem
> mentioned in comment:
>
> if( UNIX )
>    # Generator library is used during compilation. If some environment not
>    # have previous kdebindings installed, will fail, then we need add local
> path
>    set( ENV{LD_LIBRARY_PATH} ${CMAKE_CURRENT_BINARY_DIR}/generator/bin )
> endif( UNIX )
>
> It seems that the only way to invoke a program in modified environment with
> CMake is to create a wrapper script.

If you set(ENV{FOO} bar) in a CMakeLists.txt, this sets the env.var FOO at the 
moment when this command is executed, i.e. at cmake-time. This means it won't 
be set later at build time (when the makefiles are executed).

You may file a feature request to support an ENVIRONMENT argument so that it 
is possible to set env.vars for the executed process.

But, beside that, the code above looks wrong, I think this patch should be 
simply reverted:
http://websvn.kde.org/trunk/KDE/kdebindings/CMakeLists.txt?r1=1013460&r2=1024969

By default, when an executable is built by cmake, and if that executable links 
to a shared library in the same project, the executable is built with the 
RPATH pointing to this library in the build tree, so it can always be 
executed during the build.

What's going wrong without this patch ?
Is the "generator" executed during the cmake step ? (this should be 
impossible, since at cmake-time the generator has not yet been built).
So I assume that the patch actually does nothing at all, it neither fixes or 
breaks something.

Why is the call 

add_subdirectory(generator) 

even before the find_package(KDE4) in the top level CMakeLists.txt ?
This looks wrong.

Alex