GitLab

Ben Boeckel authored Aug 07, 2013 and Brad King committed Sep 20, 2013

This is useful for cases like:

  add_test(NAME mytest COMMAND mydriver $<TARGET_FILE:myexe>)
  set_tests_properties(mytest PROPERTIES
    REQUIRED_FILES "$<TARGET_FILE:myexe>"
    WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIGURATION>"
    )

In this example we require the actual test executable to exist to
run the test in addition to the test driver at argv[0].  Also the
$<CONFIGURATION> expression improves over \${CTEST_CONFIGURATION_TYPE}
because the latter is not normalized for case-sensitive filesystems.

The extendResult method expects a non-empty parameters vector, as
assured by the normal case. Avoid calling the method when the parser
finds an incomplete generator expression, but has already entered
the state of expecting to find parameters.

* The ALIAS name must match a validity regex.
* Executables and libraries may be aliased.
* An ALIAS acts immutable. It can not be used as the lhs
  of target_link_libraries or other commands.
* An ALIAS can be used with add_custom_command, add_custom_target,
  and add_test in the same way regular targets can.
* The target of an ALIAS can be retrieved with the ALIASED_TARGET
  target property.
* An ALIAS does not appear in the generated buildsystem. It
  is kept separate from cmMakefile::Targets for that reason.
* A target may have multiple aliases.
* An ALIAS target may not itself have an alias.
* An IMPORTED target may not have an alias.
* An ALIAS may not be exported or imported.

Stephen Kelly authored Jul 15, 2013 and Brad King committed Jul 24, 2013

The old code checked only that there was a LOCATION for the
specified config, but did not check whether the config actually
mapped.

Task-number: 14292

Avoid command lines beyond NMake limits.

 http://open.cdash.org/testDetails.php?test=196577461&build=2949683
 expanded command line '...' too long

As the comma is the parameter separator, it needs to be re-added
when evaluating to reconstruct arbitrary content.

Jean-Christophe Fillion-Robin authored Mar 12, 2013 and Brad King committed Mar 12, 2013

This expression is useful to put a ';' in a command line argument
without dividing the argument during CMake list expansion.

This means that we can use expressions of the form

 $<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>

to get a list of the interface include directories of foo, including
those coming from dependencies.

We can't have a test of a target which has a single include directory in
its INCLUDE_DIRECTORIES because the shell on the MSYS platforms transforms
a single include directory to include a prefix, which is not what the test
expects. We test a target with two directories instead as a means to
test a target with no link dependencies.

An empty string is not likely going to produce expected results
in any evaluation context. It is replaced by preprocessing
currently.

It will be used as a preprocessing marker.

This is for specifying INCLUDE_DIRECTORIES relevant to the build-location
or the install location for example:

 set_property(TARGET foo PROPERTY
   INTERFACE_INCLUDE_DIRECTORIES
   "$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};${CMAKE_CURRENT_SOURCE_DIR}>"
   "$<INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include>"
 )

A 'bar' target can then use:

 set_property(TARGET bar PROPERTY
   INCLUDE_DIRECTORIES
   "$<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>"
 )

and it will work whether foo is in the same project, or an imported target
from an installation location, or an imported target from a build location
generated by the export() command.

Because the generator expressions are only evaluated at build-time, these
new expressions are equivalent to the ZeroNode and OneNode.

The GeneratorExpression test is split into parts. Some shells can't run
the custom command as it is getting too long.

Stephen Kelly authored Nov 01, 2012 and Brad King committed Nov 05, 2012

This fixes a regression introduced by commit f1eacf0e
(cmGeneratorExpression: Re-write for multi-stage evaluation).

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.

Stephen Kelly authored Oct 16, 2012 and Brad King committed Oct 17, 2012

The '<<' is a special sequence on those platforms, so it can't appear in
the test.

Stephen Kelly authored Oct 12, 2012 and Brad King committed Oct 17, 2012

Content which is incomplete as a generator expression could cause
segfaults by advancing an iterator beyond end() and dereferencing
it. Such incomplete generator expressions  should be treated as
plain text instead.

Stephen Kelly authored Oct 12, 2012 and Brad King committed Oct 17, 2012

The rationale is similar to that in commit b3d8f5da (GenEx: Parse comma
after colon tokens specially, 2012-10-04), in that colon tokens should
not be parsed as identifier-argument delimiters after the first colon.

Stephen Kelly authored Oct 04, 2012 and Brad King committed Oct 09, 2012

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.

Stephen Kelly authored Sep 12, 2012 and Brad King committed Sep 28, 2012

Generator expressions for comparing strings, evaluating
strings as booleans, and for creating literal right-angle-brackets
and commas are added. Those may be needed in some cases
where they appear in literals.

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.