Feature Request: `PROPAGATED_PROPERTIES` target property
Currently, the only mechanism to propagate custom properties is the COMPATIBLE_INTERFACE_[BOOL,STRING,NUMBER_MIN,NUMBER_MAX]
properties. These properties enforce consistency between linked targets and are very useful.
However, these properties insufficient to implement several desirable behaviors. Specifically, providing support for the evaluation the concatenation or union of a list-type property amongst linked targets. This is the behavior (as I understand it at least) of several built-in properties, e.g. INTERFACE_COMPILE_OPIONS or INTERFACE_SOURCE_FILES.
I propose the addition of a new built-in property PROPAGATED_PROPERTIES
to allow custom properties to opt into this behavior, e.g.
set_property(TARGET myLib0 APPEND PROPERTY PROPAGATED_PROPERTIES myCustomProperty)
set_property(TARGET myLib0 APPEND PROPERTY INTERFACE_myCustomProperty foo bar)
set_property(TARGET myLib1 APPEND PROPERTY PROPAGATED_PROPERTIES myCustomProperty)
set_property(TARGET myLib1 APPEND PROPERTY INTERFACE_myCustomProperty baz)
target_link_library(myExe PUBLIC myLib0 myLib1)
get_target_property(values myExe myCustomProperty)
message("values: ${values}")
would result in
values: foo;bar;baz
If concatenation is provided, union could be implemented in the host component via a REMOVE_DUPLICATES
generator expression (should that feature be implemented).
Motivating Example:
The Intel fortran compiler is supported by several projects within my organization. There are several compiler options specified as arguments to the assume
flag, e.g.
-assume nobscc,protect_parens
or-assume nobscc -assume protect_parens
Specifying these flags using the latter convention is problematic as a result of CMake's flag deduplication. For this example, the resulting compilation command is
-assume nobscc protect_parens # protected_parens is not a recognized flag =(
Within a project, these flags can be specified in a centralize location to avoid the issue (although that can be inconvenient), but this proves problematic if these sorts of flags appear in the interface compile options of multiple linked subproject libraries.
To work around the compiler flag deduplication, we use a custom property to manage assume
arguments in combination with a COMPILE_OPTION
generator expression, i.e.
add_library(IntelAssumptions INTERFACE)
string(CONCAT generator
"$<$<AND:$<STREQUAL:Intel,${CMAKE_Fortran_COMPILER_ID}>,"
",$<BOOL:$<TARGET_PROPERTY:Intel_ASSUMPTIONS>>"
">"
":$<IF:$<PLATFORM_ID:Windows>"
",/assume$<1::>"
",-assume "
">"
"$<JOIN:$<TARGET_PROPERTY:Intel_ASSUMPTIONS>,$<COMMA>>"
">")
target_compile_option(IntelAssumptions INTERFACE ${generator})
Where this might be consumed as
add_library(Foo)
target_sources(Foo PRIVATE foo.f90)
set_property(TARGET Foo APPEND PROPERTY
Intel_ASSUMPTIONS nobscc protect_parens)
target_link_library(Foo PUBLIC IntelAssumptions)
This strategy accomodates the in-project assumption flag specification, but has proven insufficient to accomodate the interproject case. Perhaps there is a clever solution leveraging $<TARGET_PROPERTY:LINK_DEPENDS>
, JOIN
, and GEN_EX
that could accomodate, but thus far we've not been able to arrive at such a solution.