Existing single-parameter expressions work due to special casing
which assumes that if there is only one parameter, and the node
accepts arbitrary content, then the result is the input.
This is true for the existing expressions matching that
pattern - namely the "1" and "TARGET_NAME" expressions. However,
the LOWER_CASE, and UPPER_CASE expressions should also accept
arbitrary content, and in their case, the result is not the input.
Refactor the cmGeneratorExpressionEvaluator to allow that extension.
Actually evaluate the "1" and "0" nodes.
Manually update reStructuredText formatting. Use a definition list
for the possible if() tests supported. Add inline literal markup
as appropriate. Also make minor wording tweaks to make it flow
better with the new markup.
Added a new variable CPACK_WIX_PATCH_FILE that users can point at an
XML patch file. Fragments defined within the patch file will be inserted
at supported insertion points (currently Component, File and Directory).
Instead of running many small tests with many cmake projects, simply
compare the generated export header against a reference.
Remove the helper macros and the try_compiles which are duplicates
of the library build tests.
As we're iterating over IMPORTED targets now, handle them in
the loop body. The existing behavior is harmless because generally
nothing is done anyway for IMPORTED targets in these code paths,
because they do not have sources for example.
If TortoiseSVN is not installed in the default path, the svn executable
installed by TortoiseSVN is not found.
Using the registry key should always find it.
Commit b04f3b9a (Create make rules for INTERFACE_LIBRARY
targets., 2013-08-21) extended the makefile generator to create
build targets for INTERFACE_LIBRARY targets. No other generators
were extended with this feature.
This conflicts with the feature of whitelisting of target properties
read from INTERFACE_LIBRARY targets. The INTERFACE_* properties
of the INTERFACE_LIBRARY may legitimately contain TARGET_PROPERTY
generator expressions for reading properties from the 'head target'.
The 'head target' would be the INTERFACE_LIBRARY itself when creating
the build rules for it, which means that non-whitelisted properties
would be read.