Extend the genex added by commit ca6ba3fee5 (Genex: Add a SHELL_PATH
expression, 2015-09-24, v3.4.0-rc1~37^2) to accept a `;`-list of paths,
convert them all, and generate a list separated by the native shell
`PATH``` separator.
Adds `Fortran_COMPILER_ID` and `Fortran_COMPILER_VERSION` generator
expression support to match equivalent `C_COMPILER_ID`,
`CXX_COMPILER_ID`, `C_COMPILER_VERSION`, and `CXX_COMPILER_VERSION`
support.
This is very helpful in the case where the C/C++ compiler suite is a
different type of compiler from the platform Fortran compiler and
projects use generator expressions to assign compiler flags and
definitions. (e.g. `GNU` C/C++ and `SunPro` Fortran on Linux)
The old behavior of $<IN_LIST:...> is inconsistent with that of
if(IN_LIST), in that it does not find an empty search item even if
the list contains empty items. This change adds a new policy to
correctly handle empty items and make the behavior more consistent
with if(IN_LIST).
Fixes: #18556
Evaluate to false on `$<COMPILE_LANGUAGE:Lang>` if language `Lang`
is not loaded. This is helpful in exported targets consumed in other
projects that may not enable all the same languages.
Fixes: #17952
Rather than injecting `CMakeLists.txt` files into each target's
`SOURCES`, teach the generators to add them during generation using
dedicated code. This avoids mutating the original targets, and avoids
polluting `$<TARGET_PROPERTY:foo,SOURCES>` with generator-specific
content.
This also avoids listing the `CMakeLists.txt` sources in the results of
`CMAKE_DEBUG_TARGET_PROPERTIES==SOURCES` so the `RunCMake.TargetSources`
test no longer needs a separate case for IDEs.
Refactoring in commit v3.8.0-rc1~445^2~2 (cmTarget: Move sanity checks
and computed property access to callers, 2016-10-13) exposed a typo in
commit v3.8.0-rc1~445^2~3 (cmGeneratorTarget: Implement
cmTargetPropertyComputer interface, 2016-10-13). Together they broke
the `$<TARGET_PROPERTY:mytgt,SOURCES>` generator expression in the case
that the `SOURCES` target property is populated in part by the
`target_sources` command. Add the missing `;`-separator.
Fixes: #17243
This allows a single condition to be used to choose between two
alternatives. Without this the condition must be duplicated with
one surrounded by `NOT`.
Closes: #15585
The GetProperty method is now just accessing contained data, meaning it
can be implemented in cmState.
Remove the cmMakefile context from the signature as a result and remove
the overload with the same signature.
Add a GetComputedProperty to cmTarget so that templates can be properly
instantiated. Otherwise the Commands would need to be able to reach the
specializations which are currently in cmTarget.cxx.
As a side-effect, the CMP0026 warning now gives a backtrace to the
target when issued from a generator expression.
When `$<LINK_ONLY:...>` is used outside of linking we may evaluate it
without a `dagChecker`. Do not dereference the NULL pointer and issue a
diagnostic instead.
Closes: #16287
Policy CMP0026 deprecated the LOCATION property, and we have long
provided a $<TARGET_FILE:...> generator expression. However, if
a project tries to use $<TARGET_PROPERTY:...,LOCATION> we should
at least not crash.
The compatibility implementation of the LOCATION property uses
cmGlobalGenerator::CreateGenerationObjects to create the structures
needed to evaluate the property before generation starts. The
implementation assumed that accessing the property could only be done
during configuration (via the typical get_property command use case).
The $<TARGET_PROPERTY:...,LOCATION> genex causes the LOCATION property
to be accessed during generation. Calling CreateGenerationObjects
during generation blows away all the objects currently being used for
generation and is not safe. Add a condition to call it only when
configuration is not finished.
Some commands on Windows do not understand forward slash paths and
require backslashes. In order to help projects generate shell
invocations of such commands, provide a generator expression to convert
paths to the shell-preferred path format for the current generator.
This will allow custom commands to generate paths the same way CMake
does for compiler command invocations.
Since support for generator expressions was added to OUTPUT_NAME it is
possible for project code to cause recursion in this method by using a
$<TARGET_FILE> genex. Detect and reject such cases.
If {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY is set with a genex then
do not add the per-config subdirectory on multi-config generators.
This will allow projects to use $<CONFIG> to place the per-config
part of the directory path somewhere other than the end.
For complex*, CustomCommand and OutDir tests, non-ascii paths
are avoided in test code by using relative paths, and setting
the working when running the test. This also avoids the
need to internationalize the test code.
For RunCMake.GeneratorExpression, use a UTF-8 encoding in
file(STRINGS) to retrieve the compiled absolute path correctly.
This is consistent with other similar expressions such as PLATFORM_ID,
and makes the CONFIGURATION expression obsolete.
Fix an off-by-one error in
GeneratorExpressionContent::EvaluateParameters exposed by a unit test.
Remove the test for 'bad' nullary use of $<CONFIG>.
Add a unit test to verify that $<CONFIG> and $<CONFIGURATION> have
the same value.
Teach the cmGeneratorExpressionEvaluator filesystem artifact logic
to reject OBJECT_LIBRARY targets since they have no main artifact.
Without the explicit rejection evaluation falls through to an
internal CMake error message in cmTarget::GetOutputInfo.
Extend the RunCMake.GeneratorExpression test to cover these cases.
Set the minimum required version of CMake high enough to avoid the
warning for CMAKE_LEGACY_CYGWIN_WIN32. The warning appears on stderr
and breaks the expected output matching.
It should be possible for example to do this:
"$<AND:${FOO},$<BOOL:${TGT}>,$<BOOL:$<TARGET_PROPERTY:${TGT},PROP>"
such that it works simliarly to the C code:
if (foo && tgt && tgt->prop())
{
}
The example of generator expression code is a little bit contrived as
it could be written other ways with the same functionality. Nevertheless,
as these cases already work and are intentional, test for them.
Otherwise the comma is treated as plain text by ParseContent.
$<STREQUAL:,> should be valid and true.
$<STREQUAL:,something> should be valid and false.
$<STREQUAL:,,> should be non-valid as it is 3 parameters.
$<STREQUAL:something,,> should be non-valid as it is 3 parameters.
Additionally, this allows reporting the correct error for other
expressions. For example $<TARGET_PROPERTY:,> should be invalid
because it has an empty target and empty property. It shouldn't
attempt to read the property ',' on the 'implicit this' target.
The expressions may be parsed and then cached and evaluated multiple
times. They are evaluated lazily so that literals such as ',' can be
treated as universal parameter separators, and can be processed from
results without appearing literally, and without interfering with the
parsing/evaluation of the entire expression.
This expression evaluates to '1' or '0' to indicate whether the build
configuration for which the expression is evaluated matches tha named
configuration. In combination with the "$<0:...>" and "$<1:...>"
expressions this allows per-configuration content to be generated.
Add generator expressions that combine and use boolean test results:
$<0:...> = empty string (ignores "...")
$<1:...> = content of "..."
$<AND:?[,?]...> = '1' if all '?' are '1', else '0'
$<OR:?[,?]...> = '0' if all '?' are '0', else '1'
$<NOT:?> = '0' if '?' is '1', else '1'
These will be useful to evaluate (future) boolean query expressions and
condition content on the results. Include tests and documentation.
