[cmake-developers] [CMake 0012589]: add_test() BROKEN: docs say target allowed, yet fails to evaluate properties (e.g. custom CMAKE_RUNTIME_OUTPUT_DIRECTORY)

Mantis Bug Tracker mantis at public.kitware.com
Wed Nov 23 05:15:37 EST 2011


The following issue has been SUBMITTED. 
====================================================================== 
http://www.itk.org/Bug/view.php?id=12589 
====================================================================== 
Reported By:                Andreas Mohr
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   12589
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2011-11-23 05:15 EST
Last Modified:              2011-11-23 05:15 EST
====================================================================== 
Summary:                    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 Reproduce: 
cmake_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)
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-11-23 05:15 Andreas Mohr   New Issue                                    
======================================================================




More information about the cmake-developers mailing list