|
Notes |
|
|
(0037838)
|
|
Brad King
|
|
2015-01-27 11:01
|
|
|
You should be able to use file(GENERATE) for this. |
|
|
|
(0037839)
|
|
Brad King
|
|
2015-01-27 11:02
|
|
|
Actually by definition generator expressions are not evaluated until generate time, so file(GENERATE) files will not be available to re-include() by a module during configuration. In general it is not possible to evaluate generator expressions during the configuration process. |
|
|
|
(0037860)
|
|
raspy
|
|
2015-01-29 16:05
|
|
I guess that at some point in generation there is a function called to evaluate expression. Maybe such function could be provided for explicit use as a variant of set()? I think it would be enough if it could just evaluate as much as it could, if the result can be evaluated - evaluate, i.e.:
- $<$<CONFIG:DEBUG>:-g> - evaluate, current config is known
- $<TARGET_FILE:tgt> - evaluate if tgt was already defined, otherwise throw error |
|
|
|
(0037861)
|
|
Brad King
|
|
2015-01-29 16:12
|
|
Re 0015375:0037860: Properties set on targets after the evaluation can affect their location. We created generator expressions exactly because not all information is known during configuration.
FYI, you can at least get a genex-free string by using the string(GENEX_STRIP) command in CMake 3.1:
http://www.cmake.org/cmake/help/v3.1/command/string.html [^]
Or, perhaps you can achieve what you want with a try_compile whole-project signature call. That will do generation in the tested project. Perhaps in combination with file(GENERATE) something can be made to work.
What is it that you're trying to run with execute_process anyway? |
|
|
|
(0037862)
|
|
raspy
|
|
2015-01-30 04:33
|
|
I need to configure external 3rd party library to make it compile with the same options as application. This is performed by running external make and passing compilation options on the command line.
Stripping generator expressions avoids syntax error, but still does not allow passing the same flags. Generator expressions are here used rather as a short-hand for simple conditions, like I presented before:
$<$<CONFIG:DEBUG>:-g>
$<$<BOOL:FEATURE1_SUPPORT>:-DFEATURE1_SUPPORT>
etc.
It is indeed very convenient syntax, so it gets used. But when I need to pass it somewhere external, I get unresolved genexes. They might be stripped as you mentioned, but then I miss compilation options and/or flags which should be set as well. |
|
|
|
(0037864)
|
|
Brad King
|
|
2015-01-30 08:15
|
|
|
Re 0015375:0037862: Can the configuration and build of the external library wait until build time of the CMake project? With that approach you could use file(GENERATE) to prepare the configuration script, or possibly add_custom_command to directly run the configuration step. We commonly use the ExternalProject module for this, though it does not automatically forward all flags. |
|
|
|
(0037877)
|
|
raspy
|
|
2015-02-02 03:57
|
|
|
Actually the tricky thing is that as part of configuration this library provides a set of defines which will need to be provided for the application compilation. That's how it is tied with each other :-/ We provide them compilation flags, it provides us define/linking symbols. |
|
|
|
(0042705)
|
|
Kitware Robot
|
|
2016-06-10 14:29
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|