All KWSys C symbol names begin with the KWSYS_NAMESPACE defined at
configuration time. For ease of editing we write canonical names with
the prefix 'kwsys' and use macros to map them to the configured prefix
at preprocessing time. In the case of standalone KWSys, the prefix is
'kwsys', so the macros were previously defined to their own names.
We now skip defining the macros in the identity case so that the final
symbol names are never themselves macros. This will allow the symbols
to be further transformed behind the scenes to help linkers in special
cases on some platforms.
Linking to a Windows shared library (.dll) requires only its import
library (.lib). This teaches CMake to recognize SHARED IMPORTED library
targets that set only IMPORTED_IMPLIB and not IMPORTED_LOCATION.
When an IMPORTED target provides no generic configuration and no match
for a desired configuration then we choose any available configuration.
This change corrects the choice when the first listed available
configuration does not really have a location.
Previously KWSys SystemInformation parsed this file assuming a strict
order and set of fields, but the order is not reliable. This
generalizes the implementation to support any order and extra fields.
The transitive link dependencies of a linked target must be followed in
its own scope, not in the scope of the original target that depends on
it. This is necessary since imported targets do not have global scope.
See issue #8843.
The previous wording of the VERBATIM option documentation in the
add_custom_command and add_custom_target commands was confusing. It
could be interpreted as the opposite of what the option means (no
escaping instead of escaping). This clarifies the documentation to
explicitly state that it escapes.
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.
