summaryrefslogtreecommitdiffstats
path: root/Help/command/target_link_options.rst
Commit message (Collapse)AuthorAgeFilesLines
* Help: Move a note about arguments and genexes into include fileAlex Turbov2022-11-091-4/+2
|
* Help: Add _See Also_ sections to related CMake commandsAlex Turbov2022-11-091-0/+12
|
* Help: Link from usage requirement commands to detailed explanationHinell2022-09-161-3/+3
| | | | | | | Augment vague mentions of "Transitive Usage Requirements" with links to a detailed explanation. Fixes: #23799
* 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: Add Sphinx 'versionadded' directives to each top-level documentKitware Robot2020-07-061-0/+2
| | | | | | | Run the `Utilities/Sphinx/update_versions.py` script to add initial markup to every top-level document and find module. Issue: #19715
* CUDA: Device linking use now link optionsMarc Chevrier2020-04-191-0/+2
| | | | | | | | | | properties LINK_OPTIONS and INTERFACE_LINK_OPTIONS are propagated to the device link step. To control which options are selected for normal link and device link steps, the $<DEVICE_LINK> and $<HOST_LINK> generator expressions can be used. Fixes: #18265
* Help: Clarify that link options don't apply to static library targetsCraig Scott2019-05-051-9/+15
|
* Merge topic 'doc-updates'Brad King2018-10-261-2/+2
|\ | | | | | | | | | | | | 2f9c253961 Help: clarify "LINKER:" prefix usage Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !2530
| * Help: clarify "LINKER:" prefix usageMarc Chevrier2018-10-261-2/+2
| | | | | | | | Fixes: #18503
* | 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.
* LINK_OPTIONS: Add support of "LINKER:" prefixMarc Chevrier2018-06-061-1/+3
|
* LINK_OPTIONS: Add new family of propertiesMarc Chevrier2018-06-061-0/+40
This family enable to manage link flags Three new properties: * directory property: LINK_OPTIONS * target properties: LINK_OPTIONS and INTERFACE_LINK_OPTIONS Two new commands * add_link_options(): to populate directory property * target_link_options(): to populate target properties Fixes: #16543
generated by cgit v0.12 at 2025-01-04 02:58:11 (GMT)