summaryrefslogtreecommitdiffstats
path: root/Help/command/target_compile_definitions.rst
Commit message (Collapse)AuthorAgeFilesLines
* Help: Describe definition values in target_compile_definitionsJuan Ramos2020-11-301-0/+9
| | | | Fixes: #20573
* Help: Add `.. versionadded` directives to commands documentationNikita Nemkin2020-11-091-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Help: Apply syntax highlighting to project commandsJoachim Wuttke (o)2018-10-251-2/+2
| | | | | | * Replace most "::" by ".. code-block:: cmake" * Header sentence in imperative voice, detailed command description in present tense.
* Help: Document target_compile_definitions handling of -DRuslan Baratov2018-03-201-0/+10
| | | | | Add an example of using the `target_compile_definitions` command and a note about usage of ``-D`` in items.
* Teach target_* commands to set INTERFACE properties of IMPORTED targetsDeniz Bahadir2017-10-261-3/+4
| | | | | | | | | | | 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
* Help: Fix formatting of command parameter.Stephen Kelly2015-02-171-1/+1
|
* Help: Mark up the buildsystem commands documentationStephen Kelly2014-02-061-14/+18
| | | | Cross-link to the cmake-buildsystem manual.
* Help: Use ``inline-literals`` to mark generator expressions.Stephen Kelly2014-02-061-1/+1
|
* Help: Factor out cmake-generator-expressions manual pageBrad King2013-10-161-75/+3
| | | | | | | | | Generator expressions are supported in many places and are a distinct concept worthy of their own manual page. The old builtin documentation was previously represented by preprocessor macros to generate it into each place that supports them. Factor out the duplicate content into a dedicated cmake-generator-expressions manual page and reference it from each original location.
* Convert builtin help to reStructuredText source filesKitware Robot2013-10-151-0/+96
Run the convert-help.bash script to convert documentation: ./convert-help.bash "/path/to/CMake-build/bin" Then remove it.