| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Fixes: #19712
|
| |
|
|
|
|
|
|
| |
`.. 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
|
| |
|
|
|
|
|
|
| |
Since commit v3.0.0-rc1~260^2~32 (ctest_build: Use "cmake --build"
to launch the native build tool, 2013-11-14) we no longer need to
use the project name in `ctest_build()`.
Fixes: #18612
|
| |
|
|
|
|
| |
Explicitly state that this marks the `.xml` to tell the dashboard
server to append it to previously submitted results and that it
does not cause results to be appended to the `.xml` file.
|
| |
|
|
|
|
|
| |
If a `ctest_*` command has CAPTURE_CMAKE_ERROR then any errors generated
by cmake during that command will cause the value to be assigned `-1`.
This will prevent a `ctest -S` script from returning non-zero unless the
script explicitly calls `message(FATAL_ERROR)`.
|
| |
|
|
|
|
| |
Revise documentation for the major dashboard client step ``ctest_*``
commands. Modernize the documentation formatting. Add some missing
options.
|
| | |
|
| | |
|
| |
|
|
| |
Adds markup and links to other sections.
|
| | |
|
| | |
|
| | |
|
|
|
Run the convert-help.bash script to convert documentation:
./convert-help.bash "/path/to/CMake-build/bin"
Then remove it.
|
