View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011671CMakeCMakepublic2011-01-09 15:182011-01-12 08:15
ReporterAndreas Pakulat 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSLinuxOS Version
Product VersionCMake 2.8.3 
Target VersionCMake 2.8.4Fixed in VersionCMake 2.8.4 
Summary0011671: changing RUNTIME_OUTPUT_DIR after fetching LOCATION fails
DescriptionAttached is a simple cmake project which is supposed to put the setup binary into the top-level build directory, but puts it into the bin/ directory as set via CMAKE_RUNTIME_OUTPUT_DIRECTORY. The reason for this is that the LOCATION property of the target is being read and this seems to cause cmake to not update it anymore later on.

Commenting out the get_property line will put the binary into the top-level build directory.

I think this should either be allowed, with the implication that one needs to re-fetch the LOCATION property. Or it should be yielding a warning to set this
property on a target where it has no effect and be documented in the cmake manual.
Steps To ReproduceRun cmake + make on the attached project, the setup binary should be in the top-level directory and not in the bin/ directory.
TagsNo tags attached.
Attached Filesgz file icon test_output_dir.tar.gz [^] (438 bytes) 2011-01-09 15:18

 Relationships

  Notes
(0024533)
Brad King (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (manager)
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 (reporter)
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 (manager)
2011-01-10 16:20

 http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_EXECUTABLE_SUFFIX [^]

 Issue History
Date Modified Username Field Change
2011-01-09 15:18 Andreas Pakulat New Issue
2011-01-09 15:18 Andreas Pakulat File Added: test_output_dir.tar.gz
2011-01-10 10:45 Brad King Assigned To => Brad King
2011-01-10 10:45 Brad King Status new => assigned
2011-01-10 11:07 Brad King Note Added: 0024533
2011-01-10 11:07 Brad King Status assigned => closed
2011-01-10 11:07 Brad King Resolution open => fixed
2011-01-10 11:29 Andreas Pakulat Note Added: 0024534
2011-01-10 11:29 Andreas Pakulat Status closed => feedback
2011-01-10 11:29 Andreas Pakulat Resolution fixed => reopened
2011-01-10 12:16 Brad King Note Added: 0024535
2011-01-10 12:26 Andreas Pakulat Note Added: 0024536
2011-01-10 12:26 Andreas Pakulat Status feedback => assigned
2011-01-10 13:07 Brad King Note Added: 0024538
2011-01-10 13:09 Brad King Note Added: 0024539
2011-01-10 16:07 Andreas Pakulat Note Added: 0024558
2011-01-10 16:20 Brad King Note Added: 0024560
2011-01-10 16:20 Brad King Status assigned => closed
2011-01-10 16:20 Brad King Resolution reopened => fixed
2011-01-12 08:15 David Cole Fixed in Version => CMake 2.8.4
2011-01-12 08:15 David Cole Target Version => CMake 2.8.4

Copyright © 2000 - 2018 MantisBT Team