Code such as
target_include_directories(foo INTERFACE
$<INSTALL_INTERFACE:include$<FOO>>
)
should be treated as a relative directory, despite the genex, after
the INSTALL_INTERFACE is stripped away.
Previously, this would generate a relative directory on export, which
would be an error on import, so no policy is needed.
Code such as
install(TARGETS ...
INCLUDES DESTINATION $<INSTALL_INTERFACE:include>
)
should behave as if the INSTALL_INTERFACE wrapper were not present.
In code such as
install(TARGETS ...
INCLUDES DESTINATION $<FOO>include
)
the generator expressions are evaluated at generate-time. Delay
determining whether each entry is a relative path until after
the generator expressions are evaluated. Such relative paths
are based relative to the CMAKE_INSTALL_PREFIX.
Export the INCLUDES DESTINATION without appending to the
INTERFACE_INCLUDE_DIRECTORIES of the target itself. That way, a target
can be exported multiple times with different INCLUDES DESTINATION
without unintended cross-pollution of export sets.
Make a C executable instead of attempting to make a C++ static
library (and not really succeeding). This was introduced in
commit 894f52f3 (Handle INTERFACE properties transitively for
includes and defines., 2012-09-23).
Stephen Kelly