rpavlik/cmake-modules

CreateLauncher: needs to be ported to generator expressions - else violates policy (use of the LOCATION) -> CMP0026

ulrichard opened this issue · 9 comments

After recently upgrading to cmake 2.8.12 I get lots of warnings like this:

1> CMake Warning (dev) at App/cmake/CreateLaunchers.cmake:204 (get_target_property):
1> Policy CMP0026 is not set: Disallow use of the LOCATION target property.
1> Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy
1> command to set the policy and suppress this warning.
1>
1> The LOCATION property should not be read from target "CppExtTest". Use the
1> target name directly with add_custom_command, or use the generator
1> expression $<TARGET_FILE>, as appropriate.
1>
1> Call Stack (most recent call first):
1> App/cmake/CreateLaunchers.cmake:281 (_launcher_produce_vcproj_user)
1> App/CMakeLists.txt:264 (create_target_launcher)
1> App/CppExt/UnitTests/CMakeLists.txt:32 (PL_ADD_UNIT_TEST)
1> This warning is for project developers. Use -Wno-dev to suppress it.

And here is the long description:

cmake --help-policy CMP0026

CMP0026

Disallow use of the LOCATION target property.

CMake 2.8.12 and lower allowed reading the LOCATION target property to
determine the eventual location of build targets. This relies on the
assumption that all necessary information is available at
configure-time to determine the final location and filename of the
target. However, this property is not fully determined until later at
generate-time. At generate time, the $<TARGET_FILE> generator
expression can be used to determine the eventual LOCATION of a target
output.

Code which reads the LOCATION target property can be ported to use the
$<TARGET_FILE> generator expression together with the file(GENERATE)
subcommand to generate a file containing the target location.

The OLD behavior for this policy is to allow reading the LOCATION
property from build-targets. The NEW behavior for this policy is to
not to allow reading the LOCATION property from build-targets.

This policy was introduced in CMake version 3.0.0. CMake version
2.8.12.20140106-gff6f80 warns when the policy is not set and uses OLD behavior.
Use
the cmake_policy command to set it to OLD or NEW explicitly.

Right, so this will require some sizeable re-writing. It should make it simpler, the catch is that it will make it hard to support both pre-generator-expression and post-generator-expression CMake version. I imagine the best course there is to actually have two separate implementation files.

Why can't we just replace the line 266 of the CreateLaunchers.cmake by:
set(USERFILE_COMMAND $<TARGET_FILE>) ??

I assume that was a generator expression that got wiped out because it looked like an HTML tag. I think the answer is "you almost can, but not quite" because of Visual Studio (it needs per-config files generated with different names).

any movement on this?

My problem is that I am setting target_destination() after the create-launcher call (and can't be easily swapped due to the structure of my files).

As a work-around I did this in place of get_target_property() calls
set(USER_COMMAND "$(TargetPath)")
set(USER_WORKING_DIRECTORY "$(TargetDir)")

This makes it use VS's variable.

Would need to be fixed up in 2 or 3 places in the code.

this PR might serve to solve this issue, #53

Since I haven't heard anything on the PR I moved it to a new repo and also added it to hunter (cmake package handler, https://github.com/ruslo/hunter) so that it will be easier to use, https://github.com/caseymcc/CreateLaunchers

sorry for missing this PR. While I still use and add to this repo, I don't use this particular module because I have a little more control over the software I work with and so it doesn't need a zillion arguments and environment variables 😉 , and where I have DLLs on Windows, I use https://stackoverflow.com/questions/6594796/how-do-i-make-cmake-output-into-a-bin-dir#6595001 to put them in the same dir. I'll look at and merge the PR if it's reasonable, which I'm sure it will be. I probably need to do a bit of fork management on this repo, pulling in changes out in the network, since it's by far my most popular original repo :)

Fixed by merging #53.