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 ====================================================================== -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers