| 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
|
| |
|
|
|
|
|
| |
Run the `Utilities/Sphinx/update_versions.py` script to add initial
markup to every top-level document and find module.
Issue: #19715
|
| | |
|
| |
|
|
|
|
| |
* Replace most "::" by ".. code-block:: cmake"
* Header sentence in imperative voice,
detailed command description in present tense.
|
| |
|
|
|
|
|
|
|
|
|
| |
Now, several `INTERFACE_*` properties can be set on `IMPORTED` targets,
not only via `set_property` and `set_target_properties` but also via
`target_compile_definitions`, `target_compile_features`,
`target_compile_options`, `target_include_directories`, `target_sources`
and `target_link_libraries`.
Fixes: #15689
Issue: #17197
|
| |
|
|
|
|
|
| |
Extend sentences in other documentation linking to this manual to
say that it has a list of supported compilers.
Co-Author: Brad King <brad.king@kitware.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Compilers enable their extensions by default, and disabling them
implicitly can lead to results which are surprising or non-obvious
to debug.
http://public.kitware.com/pipermail/cmake-developers/2014-May/010575.html
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10214
https://www.mail-archive.com/cmake-developers@cmake.org/msg10116.html
(Compiler feature extensions by default, 29 May 2014)
|
| |
|
|
|
|
|
|
| |
Link to it from the documentation of related properties, variables
and commands.
Extend the cmake-developer(7) documentation with notes on
extending feature support for compilers.
|
| |
|
|
|
|
|
|
|
|
|
| |
Add properties and variables corresponding to CXX equivalents.
Add features for c_function_prototypes (C90), c_restrict (C99),
c_variadic_macros (C99) and c_static_assert (C11). This feature
set can be extended later.
Add a <PREFIX>_RESTRICT symbol define to WriteCompilerDetectionHeader
to conditionally represent the c_restrict feature.
|
|
|
This can be used to set the compiler features required by particular
targets. An error is issued at CMake time if the compiler does not
support the required feature. If a language dialect flag is required
by the features used, that will be added automatically.
Base the target_compile_features command on cmTargetPropCommandBase. This
gives us 'free' handling of IMPORTED, ALIAS, INTERFACE, non-compilable
and missing targets.
|
