Boost logo

Boost Interest :

Subject: Re: [Boost-cmake] target property LOCATION
From: Brad King (brad.king_at_[hidden])
Date: 2009-05-21 11:21:54


troy d. straszheim wrote:
> This is documented as deprecated in cmake 2.6, but not so in 2.7.CVS. I
> think I need to get the absolute location of an executable so I can pass
> it to add_test. How should this be done?

I think 2.6.4's documentation removed the word 'deprecated'. However, the
LOCATION property is useful only in build rules and not in tests:

  "The path may contain a build-system-specific portion that is
   replaced at build time with the configuration getting built
   (such as "$(ConfigurationName)" in VS)."

Since most of Kitware's projects keep all the test executables in one
place we have no trouble with this, so the interface in 2.6 is not very
nice. One has to name the executable location *without* the per-config
part. CTest looks in the per-config subdirectory automatically based
on the configuration it is testing.

If EXECUTABLE_OUTPUT_PATH or the target's RUNTIME_OUTPUT_PATH property
is set then one must account for that manually when calling add_test:

   add_test(mytest ${EXECUTABLE_OUTPUT_PATH}/myexe arg1 arg2 ...)

However, if neither is set then the executable is built in its default
location: the build directory corresponding to its CMakeLists.txt file.
In this case no path is needed:

   add_test(mytest myexe arg1 arg2 ...)

You might be able to use LOCATION if you post-process its value to remove
the per-configuration part (present when CMAKE_CONFIGURATION_TYPES is set).

Fortunately CMake HEAD in CVS has a new signature of the add_test command
which makes this much easier:

   add_test(NAME mytest COMMAND myexe arg1 arg2 ...)

When the first argument to COMMAND (myexe in this case) names an executable
target it is automatically replaced with the right thing. I've been toying
with syntax for requesting replacement in later arguments but nothing has
been committed yet.

-Brad


Boost-cmake list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk