View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0012589CMakeCMakepublic2011-11-23 05:152012-04-02 10:10
ReporterAndreas Mohr 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
PlatformLinuxOSRHEL5OS Version
Product VersionCMake 2.8.5 
Target VersionFixed in Version 
Summary0012589: add_test() BROKEN: docs say target allowed, yet fails to evaluate properties (e.g. custom CMAKE_RUNTIME_OUTPUT_DIRECTORY)
Description[includes working/failing test case below]

At least my local CMake 2.8.5 SVN has a weird (IOW, "broken") add_test()
which will result in CTest not being able to locate the test's binary,
despite add_test() docs (even in 2.8.2, but not yet in 2.6.4) stating that it _is_ ok to simply pass the target as the executable argument to add_test().

And since aggregated, complete CMake configuration environment knowledge is put to use to create a CTest configuration,
generically spoken a "generator" _SHOULD_ always use _ALL_ its implicit
knowledge about its objects (targets) to fill in _ALL_ attributes
required within the "dumb" generated file (CTest script).
If this crucial target-based mechanism does not work, then we could just as well give up all the built-in automatic configuration elegance that CMake is supposed to offer and code everything by hand instead ;-P

I'm sufficiently puzzled that this is even failing at all, since from an object-oriented POV, it should be obvious that when querying a "target" object about its prospective location, this location should _always_ be correctly returned (and this does include properly obeying CMAKE_RUNTIME_OUTPUT_DIRECTORY within the target object implementation), completely irrespective of whether this target location request is being made by add_test() implementation or somewhere else.

I suspect that CMake upstream might even unit test this feature,
but since CTest automatically searches various output paths
(Debug, Release, etc.) in case the binary cannot be found, a test would have false-negatively worked in all cases where there has been no custom output path specified (we're using a custom bin/!).

Thanks a ton!
Steps To Reproducecmake_minimum_required(VERSION 2.8)

project(bug_add_test)

file(WRITE main.cpp "
int main()
{
  return 0;
}
")

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/bin")

add_executable(bug_add_test main.cpp)

function(hookup_test _target)
  set(testname_ "${_target}")
  set(enable_workaround false) # <---- TOGGLE THIS LINE! ----
  if(enable_workaround)
    # Work around incapable add_test(), by using a property which
    # is said to be ""deprecated""... (*** SIGH ***).
    get_property(test_location_ TARGET "${_target}" PROPERTY LOCATION)
    set(testexe_ "${test_location_}")
  else(enable_workaround)
    set(testexe_ "${_target}")
  endif(enable_workaround)
  add_test("${testname_}" "${testexe_}")
endfunction(hookup_test _target)

# enable_testing() cannot be called within function scope,
# _needs_ to be done in root (~ dir).
enable_testing()

hookup_test(bug_add_test)
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0027851)
Brad King (manager)
2011-11-23 08:08

That behavior is documented only for the newer add_test(NAME) signature's COMMAND keyword:

  add_test(NAME <name> [CONFIGURATIONS [Debug|Release|...]]
           [WORKING_DIRECTORY dir]
           COMMAND <command> [arg1 [arg2 ...]])


  http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_test [^]
  "If COMMAND specifies an executable target..."

For example:

  add_test(NAME MyTest COMMAND MyExecutable)
(0029049)
David Cole (manager)
2012-04-02 10:10

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2011-11-23 05:15 Andreas Mohr New Issue
2011-11-23 08:08 Brad King Note Added: 0027851
2011-11-23 08:08 Brad King Status new => resolved
2011-11-23 08:08 Brad King Resolution open => no change required
2011-11-23 08:08 Brad King Assigned To => Brad King
2012-04-02 10:10 David Cole Note Added: 0029049
2012-04-02 10:10 David Cole Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team