| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This expression is useful to put a ';' in a command line argument
without dividing the argument during CMake list expansion.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We should also check whether the INTERFACE_ variant of a property
is being read, and in the case of the compile definitions, we should
test the _<CONFIG> suffixed variants. That is already available
through the use of the methods.
This way, we use the ALREADY_SEEN optimization when evaluating
the includes of a target in 'external' generator expressions, ie, those
used in a add_custom_command invokation, as opposed to evaluating the
INCLUDE_DIRECTORIES of a target itself via GetIncludeDirectories.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| | |
9be64f3 GenEx: Use case insensitive comparison for $<CONFIG:...>
|
| | |
| |
| |
| |
| | |
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.
|
| |
|
|
|
| |
The '<<' is a special sequence on those platforms, so it can't appear in
the test.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
