10

I have a CMakeLists.txt that does this:

get_target_property(myloc mytarget LOCATION)

It used to work fine, but CMake 3.0 deprecated using LOCATION (see https://cmake.org/cmake/help/v3.0/policy/CMP0026.html). So I tried using a generator expression:

set(myloc $<TARGET_FILE:mytarget>)

This seemed like it would work, except that generator expressions are not evaluated everywhere, they only seem to work when setting properties of other targets, and are resolved during the "generation" step, not the earlier "configuration" step. The problem is, I need to know the target location in an install() rule, something like this (the real use is not strip but that doesn't matter):

install(CODE "execute_process(COMMAND strip ${myloc})")

This worked fine when using LOCATION but now that's deprecated and I can't figure out the right way to do this. The root of the problem seems to be that install() is invoked during the "configuration" step, when the target path is not known.

How can I bridge this gap, and discover the target output path as I used to do, before calling install()?

John Zwinck
  • 239,568
  • 38
  • 324
  • 436

2 Answers2

5

Ideally, it would be done via generator expressions:

install(CODE "execute_process(COMMAND strip $<TARGET_FILE:mytarget>)")

Unfortunately, support for generator expressions in CODE and SCRIPT modes of install command has been added only in CMake 3.14 (see documentation of install command in that version).

Before CMake 3.14 you may work only with single-configuration generators (e.g. with Makefile but not with Visual Studio).

In such conditions, you may either disable CMP0026 warning, as suggested in the Th.Thielemann's answer and read LOCATION property.

Or you may use install(SCRIPT) flow of the command, where the script is prepared with file(GENERATE) command which is like configure_file but works with generator expressions:

file(GENERATE OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/mytarget_strip.cmake
     CONTENT "execute_process(COMMAND strip $<TARGET_FILE:mytarget>)")

install(SCRIPT ${CMAKE_CURRENT_BINARY_DIR}/mytarget_strip.cmake)

Note, that the approach with file(GENERATE) still doesn't work with multi-configuration generators: CMake requires filename for OUTPUT clause to be unique between the configurations. One may "fix" that with

file(GENERATE OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/mytarget_strip.cmake_$<CONFIG>
     CONTENT "execute_process(COMMAND strip $<TARGET_FILE:mytarget>)")

install(SCRIPT ${CMAKE_CURRENT_BINARY_DIR}/mytarget_strip.cmake_${CMAKE_BUILD_TYPE})

but this still won't work: in multi-configuration generators CMAKE_BUILD_TYPE is evaluated to empty string.

(Replacing ${CMAKE_BUILD_TYPE} with $<CONFIG> in install(SCRIPT) command would work only in CMake 3.14 and after, but in these versions the whole file(GENERATE) is not needed and one may just use the very first snippet.)

Tsyvarev
  • 60,011
  • 17
  • 110
  • 153
1

You can try to use/re-enable the < v3.0 behaviour. 

cmake_policy(SET CMP0026 OLD)

See cmake-policies

Th. Thielemann
  • 2,592
  • 1
  • 23
  • 38
  • 1
    I do not want to simply disable the warning, I want a solution that does not rely on the deprecated behavior. – John Zwinck Jun 06 '19 at 07:47
  • AFAIK this does not just disable the warning but enables the old behaviour. – Th. Thielemann Jun 06 '19 at 10:46
  • The old behavior is enabled all the time, but deprecated, and the docs (https://cmake.org/cmake/help/v3.6/policy/CMP0026.html) say: *"Note The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake."* So I want to know what the correct solution is. – John Zwinck Jun 06 '19 at 12:03