|
Notes |
|
|
(0024533)
|
|
Brad King
|
|
2011-01-10 11:07
|
|
The LOCATION property has not been recommended for use since CMake 2.4. Implementing a real fix to this will introduce quite a bit of overhead for every property on every target. Furthermore projects that set location-changing properties after reading LOCATION are probably buggy anyway.
I've committed additional documentation to make the situation clear:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ffe6d77 [^] |
|
|
|
(0024534)
|
|
Andreas Pakulat
|
|
2011-01-10 11:29
|
|
|
Can you clarify wether the same 'deprecation' applies LOCATION_<CONFIG>? And if it does, whats the suggested way of getting the absolute path of an executable target from cmake? |
|
|
|
(0024535)
|
|
Brad King
|
|
2011-01-10 12:16
|
|
LOCATION_<CONFIG> is okay to use, but still has this undefined behavior. Documentation updated:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=57344977 [^]
The documentation of LOCATION explains that it is only for compatibility with 2.4. The documentation of LOCATION_<CONFIG> says nothing of the kind.
Since CMake 2.6 one can write
add_custom_command(... COMMAND myexecutable ...)
and CMake will recognize the target name "myexecutable" and replace it in the command line with the real location at build time automatically. Since CMake 2.8, add_test has supported generator expressions to refer to target locations anywhere in test command lines:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_test [^]
Starting in CMake 2.8.4, generator expressions will be supported in add_custom_command and add_custom_target too:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0cdb600 [^]
so that locations can be referenced anywhere in custom command lines.
Now, why do you need the LOCATION? |
|
|
|
(0024536)
|
|
Andreas Pakulat
|
|
2011-01-10 12:26
|
|
|
I don't need LOCATION. I need a way to provide a wrapper-executable the build-dir-relative filename of the real executable that it should start. I can't change the code at this point to simply search for the real executable using some basename, so I need to supply the path relative to the top-builddir. And LOCATION seems to be the easiest way to do that. I also don't care about generators like VS or XCode which may add special stuff into that path, I just need something that works for nmake+(gnu-)make. |
|
|
|
(0024538)
|
|
Brad King
|
|
2011-01-10 13:07
|
|
Target properties like OUTPUT_NAME_<CONFIG> affect the file name so getting the location really only makes sense given a configuration. This is why LOCATION should no longer be used. CMake does not know what configuration to use when computing the full path to the file.
LOCATION_<CONFIG> should work for your case. For the generators you are using the CMAKE_BUILD_TYPE variable holds the configuration name. Something like this might work:
if(CMAKE_CONFIGURATION_TYPES)
message(FATAL_ERROR "This project does not support multi-config generators like ${CMAKE_GENERATOR}. Use a Makefile generator.")
endif()
...
add_executable(myexe ...)
set_target_properties(myexe PROPERTIES ...)
...
string(TOUPPER "${CMAKE_BUILD_TYPE}" CONFIG)
get_property(myexe_location TARGET myexe PROPERTY LOCATION_${CONFIG}) |
|
|
|
(0024539)
|
|
Brad King
|
|
2011-01-10 13:09
|
|
|
Alternatively, if your project never sets properties to change the output name of the executable target, you should be able to just hard-code the name in your wrapper without querying the LOCATION* properties. Since your project's code is setting RUNTIME_OUTPUT_DIRECTORY to tell the executable where to go, just configure the same value into your wrapper code. |
|
|
|
(0024558)
|
|
Andreas Pakulat
|
|
2011-01-10 16:07
|
|
|
Thanks for the suggestions. I'd need to get at the filename extension too to use the hardcoding-the-output directory way, not sure there's a cmake variable/property for that but I'll find that out. Feel free to close this ticket now. |
|
|
|
(0024560)
|
|
Brad King
|
|
2011-01-10 16:20
|
|
|
test_output_dir.tar.gz (438) 2011-01-09 15:18