The wording update in commit b74819e4fe (Help: Format 'if' command
documentation, 2013-12-18, v3.0.0-rc1~227^2~1) incorrectly implied that
`AND` has higher precedence than `OR`. Although this is common in many
languages, it has never been true in CMake's implementation. Revise
the wording to clarify the precedence.
Add a test case demonstrating the order.
Fixes: #23207
The meaning of "absolute path" was previously assumed knowledge,
but a number of special cases were left unspecified. The way some of
these are handled differs to the way that cmake_path(IS_ABSOLUTE)
works, so document those special cases so that the differing behavior
between these two commands is clearly defined.
`.. versionchanged` directive might be more appropriate when
documentation refers to previous CMake version, old behavior
or a policy, and there's no new parameter or a variable involved.
Issue: #19715
This change ony concerns directives that appear in the document body.
The guidelines for inserting version directives:
* Baseline version is CMake 3.0, i.e. directives start at 3.1.
* Always use `.. versionadded::` directive, avoid ad-hoc version
references. Exception: policy pages.
* For new command signatures, put `versionadded` on a separate line
after the signature.
* For a group of new signatures in a new document section,
a single version note at the beginning of the section is sufficient.
* For new options, put `versionadded` on a separate line before
option description.
* If all the option descriptions in the list are short one-liners,
it's fine to put `versionadded` on the same line as the description.
* If multiple option descriptions in close proximity would have
the same ..versionadded directive, consider adding a single
directive after the list, mentioning all added options.
* For compact value lists and sub-option lists, put a single
`versionadded` directive after the list mentioning all additions.
* When a change is described in a single paragraph, put
`versionadded` into that paragraph.
* When only part of the paragraph has changed, separate the changed
part if it doesn't break the flow. Otherwise, write a follow-up
clarification paragraph and apply version directive to that.
* When multiple version directives are close by, order earlier
additions before later additions.
* Indent related lists and code blocks to include them in the scope
of `versionadded` directive.
Issue: #19715
In CMake 3.13.x, we had this evaluation for if() conditions:
if(a) elseif(b) else(a) endif(a)
The sensible intention of the change in commit c2efb3efcd (Help: Revise
docs on Scripting Commands, 2018-10-16, v3.14.0-rc1~505^2) was:
> "endif", "endfunction" etc: Explain that the argument is optional and
> maintained for compatibility only
Instead of "endif", it ended up being written to the documentation as
"elseif" by the commit author (oops) to if()'s page.
if(a) elseif(a!?) else() endif(a?)
Truthfully, endif()'s parameter should be an optional verbatim repeat
and not elseif()'s. If it wasn't, elseif() would be described to be the
same as if(). The rightful intended description is:
if(a) elseif(b) else() endif()
Fix that typo.
Revise docs for all "Scripting Commands", except four find_XXX
that use a macro suite of their own.
* Take full advantage of the improved syntax highlighting.
* Make consequential use of <..> placeholders.
* Clarify things here and there in the text.
Specific improvements to some command docs:
* "math": Correct description of novel hexadecimal capability.
* "if", "foreach", "while": Provide link to "endif" etc
* "foreach", "while": Mention "break" and "continue".
* "foreach": Simplify explanation of ``RANGE`` and ``IN`` signatures;
advise against negative arguments or reverse ranges (compare issue #18461)
* "endif", "endfunction" etc: Explain that the argument is optional and
maintained for compatibility only
Also replace 'expression' by 'condition' (as in the while command);
relegate optional arguments of else() and endif() to the text;
revise explanation of operator precedence in Condition Syntax section.
Some of our "cmake" code blocks do not use fully valid CMake syntax
because they have placeholders for human reference. Sphinx has
never been able to properly lex and highlight these, but now warns.
Fix each block's syntax or change to a non-cmake block as appropriate.
if(TEST TestNameThatExists) will return true if a test with the name
TestNameThatExists has been added with add_test. The syntax is similar
to if(TARGET TargetName). Since use of "TEST" as an argument to if()
could previously be interpreted as a non-keyword argument, add policy
CMP0064 to treat it as a keyword as NEW behavior.
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.
Add notes about macro arguments in the foreach, if, and list commands.
Add a section to the macro command documentation explaining in detail
how macro arguments are not variables.
