| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Most of CMake commands use it. Fix a few of them to do the same.
|
| | |
|
| |
|
|
|
|
|
|
| |
`.. 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
|
| |
|
|
|
|
|
|
|
|
| |
Update command-line options, script variables, and documentation to use
the term "group" instead of "track". The old terms are still available
for now, but they are now undocumented.
This makes our terminology more consistent with CDash. The goal of this
change is to make it more clear to our users how CTest and CDash interact
with each other.
|
| |
|
|
|
|
|
|
| |
This change reworks ctest_start() so that simply calling
ctest_start(APPEND) will read all the information from the TAG file.
On top of that, it relaxes the argument parsing for ctest_start() to
allow greater flexibility in the argument ordering, and the documentation
for ctest_start() has been cleaned up.
|
| |
|
|
|
| |
Use inline reStructuredText markup and add cross-references in more
places.
|
| |
|
|
|
| |
This suppresses all non-error messages that would have otherwise
been printed by this function.
|
| |
|
|
|
|
| |
In the ctest(1) manual and ctest_start() command documentation, convert
mentions of CTest Script variables to cross-references so they will be
rendered as links.
|
| |
|
|
|
| |
Describe the behavior of the ctest_start() command when the
CTEST_CHECKOUT_COMMAND or CTEST_CVS_CHECKOUT variable is set.
|
|
|
Run the convert-help.bash script to convert documentation:
./convert-help.bash "/path/to/CMake-build/bin"
Then remove it.
|
