[CMake] Output run-time files to single directory

Mateusz Loskot mateusz at loskot.net
Tue Sep 29 17:42:14 EDT 2009


Hi,

I'm using CMake 2.6 on Linux and Windows.
I'm migrating a not-so-big project from autotools to CMake,
for both Linux (GCC) and Window (MSVC). The structure is simple:

proj/
proj/src - build as shared and static libs
proj/app - executables linking to shared and static libs

On Linux, everything works very well as expected

mkdir build
cd build
cmake ../proj
make

Libraries go to build/src and programs to build/app.
I can go to build/app and run ./program and everything works well.
No need to call ''make install', because:

build/app$ ldd ./prog1
libxxx.so => /home/mloskot/build/src/libxxx.so


On Windows with Visual Studio it doesn't work that nice, of course.
I get similar structure of build directory and files are scattered
in similar way (+ Debug vs Release subdirectory).

In order to run app/prog1 that needs to load src/xxx.dll, I need to set
PATH environment, of course.

I would like to configure Visual Studio projects (using CMake of course)
to output all runtime elements (.exe and .dll) into common directory,
for instance build/bin/debug and build/bin/release.

I tried to fiddle about RUNTIME_OUTPUT_DIRECTORY property but I
apparently don't know how to use it.


Another and related question I have is about setting
Debugging -> Environment property
in Visual Studio project. It is file with user specific settings
(*.vcproj.*.user file). By pointing all runtime dependencies using
Environment and PATH, it is possible to run program inside Visual
Studio. Simply, in many cases, I build and link my projects against
various 3rd-party libraries from different locations and it is easier
to set PATH in Visual Studio project settings than in the system-wide
environment.

So, I found this:

http://stackoverflow.com/questions/1005901/how-to-set-path-environment-variable-using-cmake-and-visual-studio-to-run-test

and I've managed (almost) to achieve what I need using the presented
UserTemplate.vcproj trick. However, perhaps it is possible to achieve
this using some nice features from CMake 2.6 or CMake 2.8 ?

Thank you in advance for your help.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org


More information about the CMake mailing list