There are two overloads, so that it can use the operational
target when a target property is being evaluated, and a target
can alternatively be specified by name.
At this point, the generators don't chain. That comes later.
Removing the Process() API and removing the parameters from the
constructor will allow cmGeneratorExpressions to be cached and evaluated
with multiple configs for example, such as when evaluating target
properties. This requires the creation of a new compiled representation
of cmGeneratorExpression. The cmListFileBacktrace remains in the
constructor so that we can record where a particular generator
expression appeared in the CMakeLists file.
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.
This converts the CMake license to a pure 3-clause OSI-approved BSD
License. We drop the previous license clause requiring modified
versions to be plainly marked. We also update the CMake copyright to
cover the full development time range.
This introduces a new syntax called "generator expressions" to the test
COMMAND option of the add_test(NAME) command mode. These expressions
have a syntax like $<TARGET_FILE:mytarget> and are evaluated during
build system generation. This syntax allows per-configuration target
output files to be referenced in test commands and arguments.
Stephen Kelly
Brad King