link step: add support for $<LINK_LANGUAGE...> genex family
Currently, compile step options can be fine-grained controlled through generator expressions based on COMPILE_LANGUAGE
.
Link step, on the contrary, do not have the same flexibility:
- properties
LINK_LIBRARIES
andINTERFACE_LINK_LIBRARIES
do not offer the possibility to control list of libraries based on link language - properties
LINK_OPTIONS
andINTERFACE_LINK_OPTIONS
supportCOMPILE_LANGUAGE
generator expressions but it is counterintuitive because, in practice, what is used during the generator expression evaluation is the linker language.
These limitations raise many problems: see #18265 (closed) or #19757 for example.
So, I propose the following evolution:
- Introduce
$<LINK_LANGUAGE...>
generator expression family supported only during evaluation of link properties. - revoke support of
$<COMPILE_LANGUAGE..>
generator expressions duringLINK_OPTIONS
evaluation (controlled by policy) in favor of$<LINK_LANGUAGE...>
.
The problematic aspect is the handling of LINK_LIBRARIES
and INTERFACE_LINK_LIBRARIES
because the link language is only known after the evaluation of these properties. To solve this problem, a double evaluation of these properties is needed:
- A first evaluation is done where
$<LINK_LANGUAGE...>
genex are ignored. A linker language is deduced from this first evaluation. - A second evaluation is done where
$<LINK_LANGUAGE...>
genex are evaluated using the linker language deduced from the first evaluation. The linker language deduced from this second pass must be identical to the one from the first pass.
Linker language from the first and second passes must be identical because, if not, the properties cannot be evaluated correctly. The idea is that $<LINK_LANGUAGE...>
genex expressions must not change linker language.
@brad.king, @craig.scott, @robertmaynard: Comments welcome...