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

kent williams nkwmailinglists at gmail.com
Fri Feb 20 11:31:46 EST 2009


On Thu, Feb 19, 2009 at 4:25 PM, Brad King <brad.king at kitware.com> wrote:
>> 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.
>
> What code are you using to set it?  If it doesn't get cached then each
> directory should use its own value.  The only reason to cache it is if
> you want the user to be able to edit the value at CMake time.
>
The code used to set it does make it a cached value.  It was part of
some boilerplate that was unfortunately propogated throughout a bunch
of projects.

The root problem is that PostDocs and grad students who are really
smart about Image Processing and advanced mathematics are sometimes
very green as Software Engineers.  They see something like a
CMakeLists.txt file as an obstacle to implementing their great ideas,
not a fundamental tool of maintainable software development.

>> 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)
>
> FYI, I've been working on a new signature for add_test that automatically
> recognizes target names and generates the proper path for you.
>

That sounds good. Really, I'd like to configure things so that tests
stay in the project_BINARY_DIR and 'real' targets -- the ones that are
deliverable -- end up in the master bin directory, as it were.  That's
actually a perfect user for SET_TARGET_PROPERTIES, right ;-)

> AFAIK the word 'deprecated' does not appear in the documentation for
> EXECUTABLE_OUTPUT_PATH.

"This variable should no longer be used as of CMake 2.6." -- I read
this as 'deprecated'. Obviously this will have to stick around, since
a lot of Kitware and other projects still use this everywhere.


More information about the CMake mailing list