2009/2/19 kent williams <nkwmailingli...@gmail.com>: > So we have a big program (well a couple of them Brains2 and Brains3), > and a bunch of 'unbundled' programs (BRAINSFit, BRAINSDemonWarp, > BRAINSTracer etc..). > > We use SVN to add the 'unbundled' programs as subdirectories of our > BRAINS svn checkout. > > So our CMakeLists.txt files in our unbundled programs MUST work > properly as a standalone build, or as a sub-directory of BRAINS. > > We've done this, at the cost of some slight added complexity in the > unbundled CMakeLists.txt. But one thing has REALLY been kicking my > butt since CMake 2.6 -- they each set EXECUTABLE_OUTPUT_PATH, relative > to their own CMAKE_CURRENT_BINARY_DIR > > The problem? If you're running standalone, everything's fine. If > you're building inside the BRAINS tree, though, the LAST > CMakeLists.txt file in the directory tree that sets > EXECUTABLE_OUTPUT_PATH wins, and consequently executable files end up > unexpected places.
May be each project shouldn't set XXXX_OUTPUT_PATH unconditionnally but using something like: IF(NOT XXXX_OUTPUT_PATH) SET(XXXX_OUTPUT_PATH "/my/favorite/place") ENDIF(NOT XXXX_OUTPUT_PATH) this way the higher level CMakeLists.txt should drive the sub-project? (to be tested though) > So I've had to go through and change everywhere that variable occurs > with CMAKE_RUNTIME_OUTPUT_DIRECTORY, and replace LIBRARY_OUTPUT_PATH > with CMAKE_LIBRARY_OUTPUT_DIRECTORY. > > Now, ideally, you should be able set those CMAKE_*_OUTPUT_DIRECTORY > variables in your top level Makefile, and then the path properties for > targets are set, and everybody's happy. > > But this isn't the case with, for example ADD_TEST. ADD_TEST will > search for the named executable in a number of places, but not, > apparently, in CMAKE_RUNTIME_OUTPUT_DIRECTORY. So you must do your > add test like this > > add_test(gumby ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/gumbyTest args) Kind of ugly, I would say. I would say that this may be due to the fact that ADD_TEST may accept test executable which are not TARGET. Doc says: "Exename can be either an executable built by this project or an arbitrary executable on the system" moreover: "The test will be run with the current working directory set to the CMakeList.txt files corresponding directory in the binary tree." I would have expected that ctest finds the executable **anywhere** if this executable is a target built by CMake (in the same project) however it doesn't seems to be the case. May be it's worth a feature request? or a bug report? > So I guess the question is this -- how should I manage this issue? Currently I would say enforce xxxx_OUTPUT_USAGE policy for the concerned project. -- Erk _______________________________________________ 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