| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Document the deprecation warnings added by commit 5845c218d7 (Deprecate
compatibility with CMake versions older than 2.8.12, 2020-06-12,
v3.19.0-rc1~629^2) and commit 3a4791548d (Deprecate compatibility with
CMake versions older than 3.5, 2023-02-09, v3.27.0-rc1~508^2).
Fixes: #25196
|
| |
|
|
|
| |
Fixes: #21519
|
|
|
|
|
|
| |
Make it even clearer that for the signature `<version>...<version>` that
the second value is only used for policies, and is not a clamp range
of supported CMake versions.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
|
| |
The CMAKE_MINIMUM_REQUIRED_VERSION has long been set by
the cmake_minimum_required() command, but the command docs
never mentioned this. Only the variable's own docs stated this but
the variable isn't very discoverable without it being mentioned in
the command's docs as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
| |
Affects cmake_minimum_required() and cmake_policy(VERSION)
|
|
|
|
|
|
|
|
| |
Teach `cmake_minimum_required` and `cmake_policy(VERSION)` to support a
version range of the form `<min>[...<max>]`. Define this to mean that
version `<min>` is required, but known policies up to those introduced
by `<max>` will be set to `NEW`. This will allow projects to easily
specify a range of versions for which they have been updated.
|
|
|
|
|
| |
State more explicitly that `cmake_policy(VERSION)` is implied and
explain the effects it has.
|
|
|
|
|
|
| |
Implementation indicates that at least two components of VERSION must
be specified (see Source/cmCMakeMinimumRequired.cxx.) Therefore the
minor version is not optional.
|
|
|
|
|
| |
Use inline reStructuredText markup and add cross-references in more
places.
|
|
|
|
|
| |
Add a note to the cmake_minimum_required documentation about the
limits of calling it in a function.
|
|
|
|
|
|
|
|
|
| |
Many projects put their project() call first, but the actions taken
by this command can be influenced by policies and other information
set by a call to cmake_minimum_required. Document in each of these
two commands that cmake_minimum_required should be called first.
Suggested-by: Alan W. Irwin
|
|
Run the convert-help.bash script to convert documentation:
./convert-help.bash "/path/to/CMake-build/bin"
Then remove it.
|