CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-11-14T09:07:15-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25412$<AND:...> does not short-circuit2023-11-14T09:07:15-05:00Craig Scott$<AND:...> does not short-circuitStarting with CMake 3.28, the `$<AND:...>` generator expression is meant to short-circuit. Once it knows the result after processing some items (i.e. once it encounters an item that evaluates to 0), it should skip evaluating the rest of ...Starting with CMake 3.28, the `$<AND:...>` generator expression is meant to short-circuit. Once it knows the result after processing some items (i.e. once it encounters an item that evaluates to 0), it should skip evaluating the rest of the items. The following example demonstrates that this isn't being done, at least not for the case shown:
```
add_executable(genex main.cpp
$<$<AND:1,0,$<NOT_A_VALID_GENEX>>:>
)
```
Instead of skipping the `$<NOT_A_VALID_GENEX>`, it still gets processed, even though the preceding item is 0, and therefore all later items should be skipped. The error generated with CMake 3.28.0-rc4 is the following (note the extra spurious error message at the end about no sources, which is also wrong):
```
CMake Error at CMakeLists.txt:6 (add_executable):
Error evaluating generator expression:
$<NOT_A_VALID_GENEX>
Expression did not evaluate to a known generator expression
CMake Error at CMakeLists.txt:6 (add_executable):
Error evaluating generator expression:
$<NOT_A_VALID_GENEX>
Expression did not evaluate to a known generator expression
CMake Error at CMakeLists.txt:6 (add_executable):
Error evaluating generator expression:
$<NOT_A_VALID_GENEX>
Expression did not evaluate to a known generator expression
CMake Error at CMakeLists.txt:6 (add_executable):
No SOURCES given to target: genex
```
The `$<IF:...>`, `$<OR:...>` and `$<0:...>` generator expressions do not have this weakness, it only seems to be `$<AND:...>` which doesn't short-circuit in the expected way.3.28.0Martin DuffyMartin Duffyhttps://gitlab.kitware.com/cmake/cmake/-/issues/25265CLANG_TIDY property unexpected behavior with Generator Expression revaluating...2023-09-26T11:22:38-04:00Nick SchultzCLANG_TIDY property unexpected behavior with Generator Expression revaluating to empty stringI'm trying to use generator expressions in the `CXX_CLANG_TIDY` target property:
```cmake
set_property(TARGET ${TARGET} PROPERTY CXX_CLANG_TIDY "<IF:$<BOOL:TRUE>,${CLANG_TIDY_CMD},>")
```
behaves appropriately, I see clang-tidy getting...I'm trying to use generator expressions in the `CXX_CLANG_TIDY` target property:
```cmake
set_property(TARGET ${TARGET} PROPERTY CXX_CLANG_TIDY "<IF:$<BOOL:TRUE>,${CLANG_TIDY_CMD},>")
```
behaves appropriately, I see clang-tidy getting invoked with the contents of `${CLANG_TIDY_CMD}`
However, if the genex evaluates to an empty string:
```cmake
set_property(TARGET ${TARGET} PROPERTY CXX_CLANG_TIDY "<IF:$<BOOL:FALSE>,${CLANG_TIDY_CMD},>")
```
I see an unexpected result (notice the genex is present in the `--tidy` command):
```plaintext
[build] FAILED: foo.cpp.o [build] cmake -E __run_co_compile --tidy="$<IF:$<BOOL:FALSE>,clang-tidy;--config-file=clang_tidy.current;-header-filter=foo/*,>;--extra-arg-before=--driver-mode=g++" --source=foo.cpp ...
```
I would expect the previous genex statement to behave similar to:
```cmake
set_property(TARGET ${TARGET} PROPERTY CXX_CLANG_TIDY "")
```
Which does not invoke clang-tidy.
Looking in the code, I am able to see that if the general expression evaluates to an empty string, the lambda `evaluateProp` returns the original string ( `value` ) here:
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.27.6/Source/cmCommonTargetGenerator.cxx#L330-342
```cpp
auto evaluateProp = [&](std::string const& prop) -> std::string {
auto const value = this->GeneratorTarget->GetProperty(prop);
if (!value) {
return std::string{};
}
auto evaluatedProp = cmGeneratorExpression::Evaluate(
*value, this->GeneratorTarget->GetLocalGenerator(), config,
this->GeneratorTarget, nullptr, this->GeneratorTarget, lang);
if (!evaluatedProp.empty()) {
return evaluatedProp;
}
return *value;
};
std::string const tidy_prop = cmStrCat(lang, "_CLANG_TIDY");
tidy = evaluateProp(tidy_prop);
```3.27.7Orkun TokdemirOrkun Tokdemirhttps://gitlab.kitware.com/cmake/cmake/-/issues/25203When "SHELL:" is used with generator expressions, deduplication is still applied2023-08-24T10:37:00-04:00rhobisonWhen "SHELL:" is used with generator expressions, deduplication is still appliedWhen calling:
```cmake
target_compile_options(target PRIVATE "SHELL:-option A")
target_compile_options(target PRIVATE "SHELL:-option B")
```
`SHELL:...` can be used to avoid deduplication of `-option`.
However, when this construction is...When calling:
```cmake
target_compile_options(target PRIVATE "SHELL:-option A")
target_compile_options(target PRIVATE "SHELL:-option B")
```
`SHELL:...` can be used to avoid deduplication of `-option`.
However, when this construction is used with generator expressions, the deduplication is still applied and breaks compilation.
For example:
```cmake
target_compile_options(${testName} BEFORE PRIVATE
$<$<OR:$<C_COMPILER_ID:Clang>,$<C_COMPILER_ID:GNU>>:SHELL:-include "fileA.h" >)
target_compile_options(${testName} BEFORE PRIVATE
$<$<OR:$<C_COMPILER_ID:Clang>,$<C_COMPILER_ID:GNU>>:SHELL:-include "fileB.h" >)
```
The result at the command line is `-include fileA.h fileB.h` instead of `-include fileA.h -include fileB.h`.
**Note:**
If I enclose the entire SHELL option in double quotes:
```cmake
target_compile_options(${testName} BEFORE PRIVATE
$<$<OR:$<C_COMPILER_ID:Clang>,$<C_COMPILER_ID:GNU>>:"SHELL:-include fileA.h" >)
target_compile_options(${testName} BEFORE PRIVATE
$<$<OR:$<C_COMPILER_ID:Clang>,$<C_COMPILER_ID:GNU>>:"SHELL:-include fileB.h" >)
```
The result at the command line is `"\"SHELL:-include fileA.h\"" "\"SHELL:-include fileB.h\""`https://gitlab.kitware.com/cmake/cmake/-/issues/24547[FEAT] Add new generator-expression $<LIST>2023-08-16T19:13:26-04:00Marc Chevrier[FEAT] Add new generator-expression $<LIST>Generator-expressions are more and more powerful and becomes the primary way to configure many features.
Unfortunately, the genex are, in many aspects, far behind the capabilities of `CMake` scripting capabilities. The support of lists ...Generator-expressions are more and more powerful and becomes the primary way to configure many features.
Unfortunately, the genex are, in many aspects, far behind the capabilities of `CMake` scripting capabilities. The support of lists is very limited and use a completely different approach than `CMake` scripting.
For example, today, it is very complex to construct a list by adding a prefix to each element and taking care of the potential empty list:
```
$<$<BOOL:$<TARGET_PROPERTY:tgt,INCLUDE_DIRECTORIES>>:-I$<JOIN:$<TARGET_PROPERTY:tgt,INCLUDE_DIRECTORIES>, -I>
```
So, I think this will be useful to offer a new genex, (e.g. $<LIST>), for list handling offering same capabilities and syntax similar to the `list()` command (similar approach than the `$<PATH>` genex):
* Reading
* $\<LIST:LENGTH,list>
* $\<LIST:GET,list,index,...>
* $\<LIST:JOIN,list,glue>
* $\<LIST:SUBLIST,list,begin,length>
* Modification
* $\<LIST:APPEND,list,element,...>
* $\<LIST:PREPEND,list,element,...>
* etc...
With a such new genex, the example can be simply rewritten:
```
$<LIST:PREPEND,$<TARGET_PROPERTY:tgt,INCLUDE_DIRECTORIES>,-I>
```
For the implementation, to ensure the full compatibility between `list()` command and `$<LIST>` genex, a new class `cmList` can be introduced capturing all the semantics and operations of `CMake` list type. And the command and genex can rely on this class.3.27.0https://gitlab.kitware.com/cmake/cmake/-/issues/25080$<REMOVE_DUPLICATES:...>: All empty items are removed, whether duplicates or not2023-07-13T08:34:34-04:00Craig Scott$<REMOVE_DUPLICATES:...>: All empty items are removed, whether duplicates or notThis is a regression in the 3.27.0 release candidates (currently testing with RC4). Sample project which can be used to demonstrate the change in behavior since 3.26.4:
```cmake
cmake_minimum_required(VERSION 3.26)
project(tmp LANGUAGES...This is a regression in the 3.27.0 release candidates (currently testing with RC4). Sample project which can be used to demonstrate the change in behavior since 3.26.4:
```cmake
cmake_minimum_required(VERSION 3.26)
project(tmp LANGUAGES NONE)
set(list A "" B C)
file(GENERATE OUTPUT show.txt CONTENT "
REMOVE_DUPLICATES => [$<REMOVE_DUPLICATES:${list}>]
")
```
Contents of `show.txt` from CMake 3.26.4:
```
REMOVE_DUPLICATES => [A;;B;C]
```
Contents of `show.txt` from CMake 3.27.0-rc4:
```
REMOVE_DUPLICATES => [A;B;C]
```3.27.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24534Would it make sense to support $<INSTALL_PREFIX> in the install(SCRIPT) and i...2023-02-27T14:37:57-05:00David FongWould it make sense to support $<INSTALL_PREFIX> in the install(SCRIPT) and install(CODE) contexts?I'm thinking about the fact that `CMAKE_INSTALL_PREFIX` can be "overridden" by the `--prefix` option of the `--install` command, which makes it less than ideal for usage if you want that case to be handled when writing `install(SCRIPT)` ...I'm thinking about the fact that `CMAKE_INSTALL_PREFIX` can be "overridden" by the `--prefix` option of the `--install` command, which makes it less than ideal for usage if you want that case to be handled when writing `install(SCRIPT)` and `install(CODE)` commands that want to use the value of the installation directory. Or is there already a way of handling that that I'm missing?3.27.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/22507add_custom_command: Genex support in COMMENT field2022-11-22T09:48:07-05:00Scott Bloomadd_custom_command: Genex support in COMMENT fieldIm trying to add a custom command, which is working fine except the “comment” section
```cmake
add_custom_command(TARGET shared_lib POST_BUILD
COMMAND “${CMAKE_COMMAND}” -E copy “$<TARGET_FILE:shared_lib>” “$<TARGET_FILE_DIR:mainapp>/st...Im trying to add a custom command, which is working fine except the “comment” section
```cmake
add_custom_command(TARGET shared_lib POST_BUILD
COMMAND “${CMAKE_COMMAND}” -E copy “$<TARGET_FILE:shared_lib>” “$<TARGET_FILE_DIR:mainapp>/styles”
COMMENT “Adding shared lib file $<TARGET_FILE:shared_lib> to MainAppProject…\n”
)
```
The comment when run is
Adding shared lib file `$^<TARGET_FILE:shared_lib^> to MainAppProject…`https://gitlab.kitware.com/cmake/cmake/-/issues/23209Support for internal build interfaces2022-11-18T09:27:38-05:00Ben BoeckelSupport for internal build interfaces`$<BUILD_INTERFACE>` does this somewhat, but the exported build configuration target's properties still have these set. For things like project-local warning, compiler, or other such things, the ability to hide from any export would be u...`$<BUILD_INTERFACE>` does this somewhat, but the exported build configuration target's properties still have these set. For things like project-local warning, compiler, or other such things, the ability to hide from any export would be useful. Something like `$<NO_EXPORT:>` maybe? Of course, `$<INTERNAL_INTERFACE>`, `$<INTERNAL>`, `$<PRIVATE>`, `$<PROJECT_LOCAL>`, or `$<PROJECT_INTERFACE>` may be a better spellings.
This would allow using an interface target to put these on any relevant targets without having to export the interface target at all.
Existing use cases where this would help:
- VTK's warning flags (see vtk/vtk!8843)
- VTK [sanitizer settings](https://gitlab.kitware.com/vtk/vtk/-/blob/2a3b8474673f677147d6c5ff8d1fbe66af5cabf4/CMake/vtkSanitize.cmake) shouldn't affect those that use the build tree versus its install tree
Cc: @brad.king @craig.scott3.26.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/23441Support for generator expressions for COMPILER/LINKER_LAUNCHER2022-09-01T10:02:14-04:00Thomas WeißschuhSupport for generator expressions for COMPILER/LINKER_LAUNCHERIt would be nice if the properties used to specify compiler and linker launchers could handle generator expressions.
I am building a linker launcher as part of the general cmake build and would like to be able to get its path through `$...It would be nice if the properties used to specify compiler and linker launchers could handle generator expressions.
I am building a linker launcher as part of the general cmake build and would like to be able to get its path through `$<TARGET_FILE:launcher>` to set the relevant properties on the targets using it.3.25.0https://gitlab.kitware.com/cmake/cmake/-/issues/15375Please provide a way to evaluate generator expressions on demand2022-07-29T09:46:37-04:00Kitware RobotPlease provide a way to evaluate generator expressions on demandThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15375). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15375). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/23795Please provide a way to evaluate generator expressions on demand2022-07-29T09:46:32-04:00Ben BoeckelPlease provide a way to evaluate generator expressions on demandThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15375). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15375). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/23498[FEAT] Add Genex $<PATH:...> for paths manipulations2022-07-13T09:11:26-04:00Marc Chevrier[FEAT] Add Genex $<PATH:...> for paths manipulationsCurrently, there is no possibility to handle paths in the context of the generator expressions, as already noticed in #23409.
The idea is to offer similar capabilities to `cmake_path()` command for genex: `$<PATH:action,path>`.
Possibl...Currently, there is no possibility to handle paths in the context of the generator expressions, as already noticed in #23409.
The idea is to offer similar capabilities to `cmake_path()` command for genex: `$<PATH:action,path>`.
Possible values for `action` will be globally the same as `cmake_path()` command:
* Decomposition: `GET_ROOT_NAME`, GET_ROOT_DIRECTORY`, `GET_FILENAME`, etc...
* Query: `HAS_ROOT_HANE`, `HAS_ROOT_DIRECTORY`, `HAS_FILENAME`, etc...
* Modification: `REMOVE_FILENAME`, `REPLACE_FILENAME`, etc...
* Generation: `NORMAL_PATH`, `RELATIVE_PATH`, etc...
* Conversions: `NATIVE_PATH`, `TO_CMAKE_PATH_LIST `, etc...
For some actions, an option can be specified as part of arguments of the genex: `$<PATH:action,[option,]path`. For example: `$<PATH:GET_EXTENSION,LAST_ONLY,/path/to/file>`.
For some other actions, multiple paths are expected: ``$<PATH:action,[option,]path1[,path2,...]`. For example:
`$<PATH:IS_PREFIX,/path/to/file,/prefix/dir>` or `$<PATH:IS_PREFIX,NORMALIZE,/path/to/file,/prefix/dir>`.
For `cmake_path(COMPARE)`, maybe the genex `$<PATH_EQUAL>` is more appropriate than `$<PATH:COMPARE,EQUAL,...>` to be consistent with `$<STREQUAL>` and `$<VERSION_EQUAL>`.https://gitlab.kitware.com/cmake/cmake/-/issues/23409Feature Request: TARGET_BUNDLE_DIR_NAME Generator Expression2022-05-11T08:17:37-04:00LeadbellyFeature Request: TARGET_BUNDLE_DIR_NAME Generator ExpressionI'd like to obtain the name of a target's bundle directory with a generator expression. Using `TARGET_BUNDLE_DIR` I can obtain the path to this directory, but there's no way to get just the name of this directory and no sensible workarou...I'd like to obtain the name of a target's bundle directory with a generator expression. Using `TARGET_BUNDLE_DIR` I can obtain the path to this directory, but there's no way to get just the name of this directory and no sensible workaround that I could find.
It seems to me that a genex something like `$<TARGET_BUNDLE_DIR_NAME:tgt>` is a missing feature.
Note: [I initially posted a help request in the forums](https://discourse.cmake.org/t/help-feature-request-target-bundle-dir-name/5374/2).3.24.0https://gitlab.kitware.com/cmake/cmake/-/issues/232033.23.0-rc1: Regression in target_link_libraries genex with multiple libs2022-02-22T15:03:11-05:00Gregor Jasny3.23.0-rc1: Regression in target_link_libraries genex with multiple libsHello,
while testing CMake 3.23.0-rc1 we found the following regression:
```cmake
cmake_minimum_required(VERSION 3.22)
project(testcase LANGUAGES C)
find_package(CURL REQUIRED)
find_package(ZLIB REQUIRED)
set(MY_LIBRARIES CURL::libc...Hello,
while testing CMake 3.23.0-rc1 we found the following regression:
```cmake
cmake_minimum_required(VERSION 3.22)
project(testcase LANGUAGES C)
find_package(CURL REQUIRED)
find_package(ZLIB REQUIRED)
set(MY_LIBRARIES CURL::libcurl ZLIB::ZLIB)
add_library(testcase STATIC foo.c)
target_link_libraries(testcase INTERFACE $<BUILD_INTERFACE:${MY_LIBRARIES}>)
install(TARGETS testcase EXPORT Testcase)
install(EXPORT Testcase DESTINATION foo)
```
This leads to the following error during generation (Ninja in our case):
```
CMake Error at CMakeLists.txt:12 (target_link_libraries):
The link interface of target "testcase" contains:
$<BUILD_INTERFACE:CURL::libcurl
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
```
The error vanishes if `MY_LIBRARIES` only contains a single library.
Could you please take a look?
Thanks,
Gregor3.23.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22007genex: $<HOST_LINK:..> and $<DEVICE_LINK:...> cannot be used in the context o...2021-08-30T14:48:58-04:00Marc Chevriergenex: $<HOST_LINK:..> and $<DEVICE_LINK:...> cannot be used in the context of try_compile/try_runGenerator expressions `$<HOST_LINK:..>` and `$<DEVICE_LINK:...> ` cannot be used in the context of `try_compile()/try_run()`.
The following snippet:
```cmake
cmake_minimum_required(VERSION 3.18...3.20)
project (test LANGUAGES C)
add_l...Generator expressions `$<HOST_LINK:..>` and `$<DEVICE_LINK:...> ` cannot be used in the context of `try_compile()/try_run()`.
The following snippet:
```cmake
cmake_minimum_required(VERSION 3.18...3.20)
project (test LANGUAGES C)
add_library(demo INTERFACE IMPORTED)
set_property(TARGET demo PROPERTY INTERFACE_LINK_OPTIONS "$<HOST_LINK:>")
file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/main.c" "int main() { return 0; }\n")
set(CMAKE_TRY_COMPILE_TARGET_TYPE EXECUTABLE)
try_compile(result "${CMAKE_CURRENT_BINARY_DIR}/tc" "${CMAKE_CURRENT_BINARY_DIR}/main.c"
LINK_LIBRARIES demo)
```
raises the following error:
```
CMake Error:
Error evaluating generator expression:
$<HOST_LINK:>
$<HOST_LINK:...> may only be used with binary targets to specify link
options.
```3.20.1https://gitlab.kitware.com/cmake/cmake/-/issues/21336Provide a way to handle target based generator expressions in file(GENERATE) ...2021-06-02T07:39:49-04:00alcroitoProvide a way to handle target based generator expressions in file(GENERATE) and add_custom_command()I'm trying to implement a 'headersclean' feature, which compiles C++ header files of a shared library with `add_custom_command` and extra compile flags, to check that there are no warnings, etc.
The gist of it is the following:
```cmak...I'm trying to implement a 'headersclean' feature, which compiles C++ header files of a shared library with `add_custom_command` and extra compile flags, to check that there are no warnings, etc.
The gist of it is the following:
```cmake
set(target "MySharedLibrary")
set(target_includes_genex "$<TARGET_PROPERTY:${target},INCLUDE_DIRECTORIES>")
set(includes_exist_genex "$<BOOL:${target_includes_genex}>")
set(target_includes_joined_genex
"$<${includes_exist_genex}:-I$<JOIN:${target_includes_genex},;-I>>")
set(target_defines_genex "$<TARGET_PROPERTY:${target},COMPILE_DEFINITIONS>")
set(defines_exist_genex "$<BOOL:${target_defines_genex}>")
set(target_defines_joined_genex
"$<${defines_exist_genex}:-D$<JOIN:${target_defines_genex},;-D>>")
set(target_compile_options_genex "$<TARGET_PROPERTY:${target},COMPILE_OPTIONS>")
set(compile_options_exist_genex "$<BOOL:${target_compile_options_genex}>")
set(target_compile_options_joined_genex
"$<${compile_options_exist_genex}:$<JOIN:${target_compile_options_genex},;>>")
set(target_compile_flags_genex "$<TARGET_PROPERTY:${target},COMPILE_FLAGS>")
set(compile_flags_exist_genex "$<BOOL:${target_compile_flags_genex}>")
set(target_compile_flags_joined_genex
"$<${compile_flags_exist_genex}:$<JOIN:${target_compile_flags_genex},;>>")
add_custom_command(
OUTPUT "${artifact_path}"
COMMENT "headersclean: Checking header ${header_path}"
COMMAND
"${CMAKE_CXX_COMPILER}" -c ${CMAKE_CXX_FLAGS}
"${target_compile_options_joined_genex}"
"${target_compile_flags_joined_genex}"
"${target_defines_joined_genex}"
"${target_includes_joined_genex}"
${hcleanFLAGS} # extra -W flags
-xc++ "${header_path}"
-o${artifact_path}
VERBATIM
COMMAND_EXPAND_LISTS)
```
This works fine for me on Windows and macOS, but breaks down on Linux with the following error:
```
CMake Error at foo.cmake:71 (target_link_libraries):
Error evaluating generator expression:
$<COMPILE_LANG_AND_ID:CUDA,NVIDIA>
$<COMPILE_LANG_AND_ID:lang,id> may only be used with binary targets to
specify include directories, compile definitions, and compile options. It
may not be used with the add_custom_command, add_custom_target, or
file(GENERATE) commands.
```
That's because a library linking against `Threads::Threads` brings in `$<$<COMPILE_LANG_AND_ID:CUDA,NVIDIA>:SHELL:-Xcompiler -pthread>` as part of the `$<TARGET_PROPERTY:${target},COMPILE_OPTIONS>` generator expression.
This is similar to https://gitlab.kitware.com/cmake/cmake/-/issues/21074
The linked issue works around it by replacing `<COMPILE_LANG_AND_ID:CUDA,NVIDIA>` with `<COMPILE_LANGUAGE:CUDA>`.
While that helps for that specific case I have a few issues with this approach:
- It handles only one specific case of a generator expression
- It requires replacing the easy to use `$<TARGET_PROPERTY:${target},COMPILE_OPTIONS>` consuming generator expression, with 100+ lines of CMake code that recursively processes a target and its dependencies to try and collect all its usage requirements by querying for `COMPILE_OPTIONS`, `COMPILE_DEFINITIONS`, etc properties. This is error prone, and might not handle all cases as a generator expression might.
Other problematic genexes are
- `$<TARGET_PROPERTY:foo>` which need to be manually replaced with `$<TARGET_PROPERTY:target,foo>`.
- `$<BUILD_INTERFACE>` / `$<INSTALL_INTERFACE>`
- `$<TARGET_POLICY>`
- `$<TARGET_OBJECTS>`
- `$<LINK_ONLY>`
I think we need a better way of handling genexes like that in the described scenario.3.21.0Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/12877Support generator expressions in OUTPUT2021-04-26T10:58:52-04:00Kitware RobotSupport generator expressions in OUTPUTThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12877). Further discussion may take place here.
---
While `$<...>` generator expressions in the COMMAND portion of add_custom_comman...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12877). Further discussion may take place here.
---
While `$<...>` generator expressions in the COMMAND portion of add_custom_command() are useful, I find their use is limited by the fact they cannot be used in other parts of add_custom_command(), such as OUTPUT. For example, in my project, I need a custom command to copy some files to the directory where a target's executable resides. In other words, I need the following:
```cmake
add_custom_command(
OUTPUT "$<TARGET_FILE_DIR:MyTarget>/TheExtraFile"
COMMAND "${CMAKE_EXECUTABLE}" -E copy Path_To/TheExtraFile "$<TARGET_FILE_DIR:MyTarget>/TheExtraFile"
VERBATIM
)
```
While in the COMMAND part, the generator expression is interpreted correctly, in OUTPUT it's not, and CMake produces an error:
```
add_custom_command called with OUTPUT containing a "<". This character is not allowed.
```3.20.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/15130support for generator expressions in OUTPUT_DIRECTORY2020-05-04T09:19:56-04:00Kitware Robotsupport for generator expressions in OUTPUT_DIRECTORYThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15130). Further discussion may take place here.
---
atm generator expressions in *_OUTPUT_DIRECTORY properties are not resolved. it ...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15130). Further discussion may take place here.
---
atm generator expressions in *_OUTPUT_DIRECTORY properties are not resolved. it would be great if this could be implemented.
https://gitlab.kitware.com/cmake/cmake/-/issues/19965link step: add support for $<LINK_LANGUAGE...> genex family2020-02-27T11:19:09-05:00Marc Chevrierlink step: add support for $<LINK_LANGUAGE...> genex familyCurrently, 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` and `INTERFACE_LINK...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` and `INTERFACE_LINK_LIBRARIES` do not offer the possibility to control list of libraries based on link language
* properties `LINK_OPTIONS` and `INTERFACE_LINK_OPTIONS` support `COMPILE_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 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 during `LINK_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:
1. A first evaluation is done where `$<LINK_LANGUAGE...>` genex are ignored. A linker language is deduced from this first evaluation.
2. 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...3.18.0https://gitlab.kitware.com/cmake/cmake/-/issues/15785Support "generator expressions" in "install(CODE)"2018-12-23T17:20:02-05:00Kitware RobotSupport "generator expressions" in "install(CODE)"This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15785). Further discussion may take place here.
---
With CMake 3.4 `install(FILES)` and `install(DIRECTORY)` learned to support ...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15785). Further discussion may take place here.
---
With CMake 3.4 `install(FILES)` and `install(DIRECTORY)` learned to support "generator expressions" in command `DESTINATION`. But it would be helpful if `install(CODE)` support "generator expressions" too.
An usecase could be:
```cmake
INSTALL(CODE "
include(BundleUtilities)
fixup_bundle($<TARGET_FILE_DIR:${PROJECT_NAME}> \"\" \"\")
" COMPONENT Runtime
)
```