[CMake] HOW TO: build development versions, plus proper INSTALL setup?
I think I've gotten myself needlessly tied into knots over
EXECUTABLE_OUTPUT_PATH vs RUNTIME_OUTPUT_DIRECTORY vs INSTALL command.
So maybe someone wants to talk me down about it.
We have a suite of programs that are built by a nested set of
directories. We'd like 2 things to happen (and a third if possible):
1. All the executables generated go into one binary directory. This
directory is what a developer would add to PATH in order to run
programs while he or she is adding source, debugging, etc.
2. When the whole package is installed, likewise, all programs would
go into one directory, most likely ${CMAKE_INSTALL_PREFIX}/bin
3. Test programs should NOT get thrown in with the actual 'product'
programs, and ideally stay in ${LOCALDIR_BINARY_DIR} for the local
project.
Right now, what I'm doing is this:
1. Set CMAKE_RUNTIME_OUTPUT_DIRECTORY and
CMAKE_LIBRARY_OUTPUT_DIRECTORY during the initial cmake configure.
2. using INSTALL(TARGETS ...) for programs
3. When I do an ADD_TEST, I give the test program's command as
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/testprogram, since setting
CMAKE_RUNTIME_OUTPUT_DIRECTORY doesn't discriminate between tests and
end-user programs.
So what _should_ I be doing, if I want to follow the One True CMake way?
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] HOW TO: build development versions, plus proper INSTALL setup?
The other items in your list looks like you have figured out so I'll
just make a suggestion for #3:
I tried the following and it does work:
# All the following in its own CMakeLists.txt file that
# will be called with add_subdirectory() from the top level
# CMakeLists.txt file.
project(UnitTests)
add_executable(foo_test foo_test.c)
target_link_Libraries(foo_test .. )
set_target_properties(foo_test PROPERTIES
RUNTIME_OUTPUT_DIRECTORY ${UnitTests_BINARY_DIR})
add_test(foo_test ${UnitTests_BINARY_DIR}/foo_test)
If you can wade through the Boost sources there is an experimental
CMake build system that I believe does a lot of this. You could
probably distill all of this down to a Macro that you could invoke to
do all of the above with just a few arguments.
Hope that helps.
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Mar 9, 2009, at 2:49 PM, kent williams wrote:
3. Test programs should NOT get thrown in with the actual 'product'
programs, and ideally stay in ${LOCALDIR_BINARY_DIR} for the local
project.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] HOW TO: build development versions, plus proper INSTALL setup?
Thanks for the suggestions. I believe that if you force all your test
programs to get thrown into ${XXX_BINARY_DIR}, you could do the
ADD_TEST without specifying ${XXX_BINARY_DIR}/testname -- just
testname would suffice.
Oh and when someone says If you can wade through the boost sources I
draw my revolver. Boost is one of those things that has all sorts of
great goodies, but when you look at actually using it, the
build/config/etc system is a deal breaker. And you can never just use
one thing from Boost -- everything in Boost has itself been Boosted,
so it doesn't seem to ever decompose into independent modules.
Not trying to give you grief, just an observation. ;-)
On Mon, Mar 9, 2009 at 3:27 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
The other items in your list looks like you have figured out so I'll just
make a suggestion for #3:
I tried the following and it does work:
# All the following in its own CMakeLists.txt file that
# will be called with add_subdirectory() from the top level
# CMakeLists.txt file.
project(UnitTests)
add_executable(foo_test foo_test.c)
target_link_Libraries(foo_test .. )
set_target_properties(foo_test PROPERTIES
RUNTIME_OUTPUT_DIRECTORY ${UnitTests_BINARY_DIR})
add_test(foo_test ${UnitTests_BINARY_DIR}/foo_test)
If you can wade through the Boost sources there is an experimental CMake
build system that I believe does a lot of this. You could probably distill
all of this down to a Macro that you could invoke to do all of the above
with just a few arguments.
Hope that helps.
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Mar 9, 2009, at 2:49 PM, kent williams wrote:
3. Test programs should NOT get thrown in with the actual 'product'
programs, and ideally stay in ${LOCALDIR_BINARY_DIR} for the local
project.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
