The value of CMAKE_CURRENT_LIST_FILE is supposed to be the list file
currently being executed. Before macros were introduced this was always
the context of the argument referencing the variable.
Our original implementation of macros replaced the context of command
arguments inside the macro with that of the arguments of the calling
context. This worked recursively, but only worked when macros had at
least one argument. Furthermore, it caused parsing errors of the
arguments to report the wrong location (calling context instead of line
with error).
The commit "Improve context for errors in macros" fixed the latter bug
by keeping the lexical context of command arguments in macros. It broke
evaluation of CMAKE_CURRENT_LIST_FILE because the calling context was no
longer preserved in the argument referencing the variable. However,
since our list file processing now maintains the proper value of
CMAKE_CURRENT_LIST_FILE with dynamic scope we no longer need the context
of the argument and can just evaluate the variable normally.
The add_definitions() command and COMPILE_DEFINITIONS dir/tgt/src
properties support preprocessor definitions with values. Previously
values were not supported in the VS6 generator even though the native
tool supports them. It is only values with spaces that VS6 does not
support. This enables support and instead complains only for values
with spaces. See issue #8779.
The CTest version control refactoring broke the value returned for the
ctest_update command's RETURN_VALUE argument. The value is supposed to
be the number of files updated, but the refactoring accidentally made it
the number of locally modified files after the update.
The RPATH target properties are initialized by CMAKE_<prop> variables at
target creation time. This notes the feature in the property
documentation. It is already noted in the variable documentation.
The patch step runs parallel to the update step since it does not make
sense to have both. Configuration of the step requires specification of
a PATCH_COMMAND argument to add_external_project.
This rewrites the keyword/argument parsing and handling in the
AddExternalProject module to use arguments more literally:
- The strict keyword-value pairing is gone in favor of keywords with
arbitrary non-keyword values. This avoids requiring users to escape
spaces and quotes in command lines.
- Customized step command lines are now specified with a single
keyword <step>_COMMAND instead of putting the arguments in a
separate entry (previously called <step>_ARGS).
- Build step custom commands now use VERBATIM mode so that arguments
are correctly escaped on the command line during builds.
This creates a new mode of the foreach command which allows precise
iteration even over empty elements. This mode may be safely extended
with more keyword arguments in the future. The cost now is possibly
breaking scripts that iterate over a list of items beginning with 'IN',
but there is no other way to extend the syntax in a readable way.
This creates global property RULE_MESSAGES which can be set to disbale
per-rule progress and action reporting. On Windows, these reports may
cause a noticable delay due to the cost of starting extra processes.
This feature will allow scripted builds to avoid the cost since they do
not need detailed information anyway. This replaces the RULE_PROGRESS
property created earlier as it is more complete. See issue #8726.
Brad King
Bill Hoffman
Alexander Neundorf
Clinton Stimpson
Philip Lowman
Francois Bertel