The commit "modified the if command to address bug 9123 some" changed
the if() command behavior with respect to named boolean constants. It
introduced policy CMP0012 to provide compatibility. However, it also
changed behavior with respect to numbers (like '2') but did not cover
the change with the policy. Also, the behavior it created for numbers
is confusing ('2' is false).
This commit teaches if() to recognize numbers again, and treats them
like the C language does in terms of boolean conversion. We also fix
the CMP0012 check to trigger in all cases where the result of boolean
coersion differs from that produced by CMake 2.6.4.
The if() command reports its arguments at the beginning of some error
messages. Originally it reported the un-expanded form of the arguments
because in ancient CMake versions no context information was available.
Now it is more useful to see the real arguments, which may be mentioned
in the main error message. Since full context information is now
available, users can refer back to the source if they need to see the
unexpanded form of the arguments.
For example, the code
set(regex "++")
if("x" MATCHES "${regex}")
endif()
now produces the message
if given arguments:
"x" "MATCHES" "++"
Regular expression "++" cannot compile
instead of
if given arguments
"x" MATCHES "${regex}"
Regular expression "++" cannot compile
This commit re-words the warning message produced for CMP0012 to avoid
the word 'you' since often the person reading the message is not the
author of the code. We also add an example of the bad OLD behavior to
the policy documentation.
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.
Errors and warnings from the if() command always display the argument
list given to the command followed by an explanation of the problem.
This moves the argument list into a pre-formatted block and follows it
with a paragraph-form explanation. The result looks cleaner.
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.
When a function blocker decides to remove itself we previously removed
it at every return point from the C++ scope in which its removal is
needed. This teaches function blockers to transfer ownership of
themselves from cmMakefile to an automatic variable for deletion on
return. Since this removes blockers before they replay their commands,
we no longer need to avoid running blockers on their own commands.
Previously bad arguments to an if() or elseif() would cause some
subsequent statements in the corresponding block to execute. This
teaches CMake to stop processing commands with a fatal error. It also
provides context to bad elseif() error messages.
Provide VERSION_LESS, VERSION_EQUAL, and VERSION_GREATER operators in
the if() command. This simplifies component-wise comparison of version
numbers in the form "major[.minor[.patch[.tweak]]]".
It is useful to be able to test if a target has been created. Often
targets are created only inside conditions. Rather than storing the
result of the condition manually for testing by other parts of the
project, it is much easier for the other parts to just test for the
target's existence. This will also be useful when find-modules start
reporting results with IMPORTED targets and projects want to test if a
certain target is available.
- This will help projects support multiple CMake versions.
- In order to set a policy when using a newer CMake but still
working with an older CMake one may write
if(POLICY CMP1234)
cmake_policy(SET CMP1234 NEW)
endif(POLICY CMP1234)
- Note that since CMake 2.4 does not have if(POLICY) supporting
it will also require using "if(COMMAND cmake_policy)"
Rolf Eike Beer
Brad King
Ken Martin
Bill Hoffman
Alexander Neundorf