From email explaining existence in the first place:
This is from before when the used checks throwing false
positives about unused due to changing the definition without
checking whether it *had* a value to begin with and me not
realizing they were false positives. I was thinking that it was
warning from ARGC et. al. not being used since the previous
macro or function call and the new value warning about
overwriting the old value.
This converts the CMake license to a pure 3-clause OSI-approved BSD
License. We drop the previous license clause requiring modified
versions to be plainly marked. We also update the CMake copyright to
cover the full development time range.
This teaches functions and macros to use policies recorded at creation
time when they are invoked. It restores the policies as a weak policy
stack entry so that any policies set by a function escape to its caller
as before.
If a logical block terminates with mismatching arguments we previously
failed to remove the function blocker but replayed the commands anyway,
which led to cases in which we failed to report the mismatch (return
shortly after the ending command). The recent refactoring of function
blocker deletion changed this behavior to produce an error on the ending
line by not blocking the command. Furthermore, the function blocker
would stay in place and complain at the end of every equal-level block
of the same type.
This teaches CMake to treat the begin/end commands (if/endif, etc.) as
correct and just warns when the arguments mismatch. The change allows
cases in which CMake 2.6.2 silently ignored a mismatch to run as before
but with a warning.
This centralizes construction of the error message for an unclosed
logical block (if, foreach, etc.). We record the line at which each
block is opened so it can be reported in the error message.
This uses an automatic variable to push and pop variable scope inside a
function call. Previously if the function failed its scope would not be
popped. This approach guarantees a balanced push/pop.
- Add cmMakefile methods IssueError and IssueWarning
- Maintain an explicit call stack in cmMakefile
- Include context/call-stack info in messages
- Nested errors now unwind the call stack
- Use new mechanism for policy warnings and errors
- Improve policy error message
- Include cmExecutionStatus pointer in call stack
so that errors deeper in the C++ stack under
a command invocation will become errors for the
command
Ben Boeckel
Brad King
Bill Hoffman
Ken Martin