Previously this behavior was only mentioned implicitly by the command
signature. Describe it explicitly as we do for other conditions that
automatically expand variables.
Fixes: #26234
Document and add explicit tests for empty string input:
`if(EXISTS "")` and `if(IS_DIRECTORY "")` are always false.
This avoids need for users to do extra checks due to
CMake non-short-circuit logic as below:
if("${p}")
if(EXISTS "${p}")
The docs for if(PATH_EQUAL) did not mention the component-wise
nature of the checks. It also claimed no normalization was
performed, but multiple separators are effectively collapsed
(part of normalization). Improve the wording to clarify both of
these points.
Also update the corresponding description of cmake_path(COMPARE),
which had the same inaccuracy.
Fixes: #23758
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.
