[CMake] EXECUTABLE_OUTPUT_PATH is not just deprecated, it's harmful!

[Eric Noulard]

2009/2/19 kent williams <nkwmailinglists at 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