summaryrefslogtreecommitdiffstats
path: root/Help/command/try_run.rst
Commit message (Collapse)AuthorAgeFilesLines
* try_run: Allow to set working directoryAsit Dhal2021-02-031-0/+7
| | | | Fixes: #17634
* Help: Add `.. versionadded` directives to commands documentationNikita Nemkin2020-11-091-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: User-provided variable names for try_* commandsCraig Scott2019-02-241-7/+7
| | | | | All uppercase is typically used for command keywords. Non-keyword arguments should generally be shown as `<something>` according to the CMake documentation guide.
* try_compile/try_run: Add support for LINK_OPTIONS option.Marc Chevrier2018-12-011-1/+6
|
* Help: Apply syntax highlighting to project commandsJoachim Wuttke (o)2018-10-251-1/+1
| | | | | | * Replace most "::" by ".. code-block:: cmake" * Header sentence in imperative voice, detailed command description in present tense.
* try_run: Use CMAKE_CROSSCOMPILING_EMULATOR.Matt McCormick2015-04-081-1/+2
| | | | | | | If the CMAKE_CROSSCOMPILING_EMULATOR variable is defined, and CMAKE_CROSSCOMPILING is TRUE, then use CMAKE_CROSSCOMPILING_EMULATOR to run the try_run executables. This prevents the need to populate TryRunResults.cmake when cross compiling.
* Help: Revise try_compile and try_run documentation (#15358)Brad King2015-02-041-45/+83
| | | | | | Rewrite the documentation using better reStructuredText markup constructs. Clarify interaction of options like LINK_LIBRARIES and CMAKE_FLAGS.
* try_run: Add support for LINK_LIBRARIES option.Matt McCormick2015-01-261-1/+8
| | | | | | | | Most functionality is already implemented in Source/cmCoreTryCompile.{h,cxx}. Document and improve argument parsing. This functionality is already being used by a number of modules, like CheckCSourceCompiles.cmake, but it is not documented.
* Convert builtin help to reStructuredText source filesKitware Robot2013-10-151-0/+52
Run the convert-help.bash script to convert documentation: ./convert-help.bash "/path/to/CMake-build/bin" Then remove it.