| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Also rename the `INVOKE` signature to `CALL`.
Fixes: #20732
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
10ee9611f0 Help: Improve wording of CMAKE_CURRENT_FUNCTION_LIST_DIR docs
22fbc404a7 Help: Add cross-references for CMAKE_CURRENT_FUNCTION* docs
d2b139687a Help: Minor grammar cleanups of CMAKE_CURRENT_FUNCTION* docs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Brad King <brad.king@kitware.com>
Acked-by: Alex Turbov <i.zaufi@gmail.com>
Merge-request: !4595
|
| | | |
|
| |/
|
|
| |
Fixes: #18392
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
`CMAKE_CURRENT_FUNCTION`
Can be used for diagnostic or debugging messages like the
`__PRETTY_FUNCTION__` macro of GCC.
`CMAKE_CURRENT_FUNCTION_LIST_DIR`
Eliminates the necessity of the additional "global"
variables inside a module used to access additional "resource"
files from functions defined in the module.
...
|
| |
|
| |
Found via `codespell`
|
| |
|
| |
Follow-up to !2616, specifically commit 22cca9b810
|
| | |
|
| |
|
|
|
|
| |
Follow our own advise not to change cases.
Omit the leading underscore.
|
| | |
|
| |
|
|
| |
Same change as previously done for function, if, while, ...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
|
|
Run the convert-help.bash script to convert documentation:
./convert-help.bash "/path/to/CMake-build/bin"
Then remove it.
|
