summaryrefslogtreecommitdiffstats
path: root/Help/command/add_custom_command.rst
Commit message (Collapse)AuthorAgeFilesLines
* Help: State behavior for add_custom_command(TARGET) without event typeCraig Scott2022-06-041-0/+5
| | | | | | | | | | Projects should always have specified one of PRE_BUILD, PRE_LINK or POST_BUILD, and the documentation has always shown that one must be given. But the argument parsing logic was such that if none was given, POST_BUILD would be used and no error or warning would be raised. Projects may be relying on this behavior, so document it as formally supported, but not recommended. Fixes: #23488
* find_* commands: add control over Windows registry viewsMarc Chevrier2022-04-291-2/+2
| | | | Fixes: #22775
* Depfile parsing: enhance compatibility with GNU MakeMarc Chevrier2022-01-161-4/+3
|
* Help: add_custom_command: describes depfile formatMarc Chevrier2022-01-111-3/+42
|
* Help: Clarify and correct wording around DEPFILE optionCraig Scott2021-07-241-18/+23
| | | | | | | The previous wording contradicted itself regarding whether Visual Studio generators were supported, and about when generator expressions could be used. Restructure the paragraphs and max it clearer what support was added in which CMake versions.
* VS: Add support for add_custom_command DEPFILEBrad King2021-06-091-3/+5
| | | | | | | | Transform the depfile into MSBuild `AdditionalInputs` content. Add MSBuild Targets to update `AdditionalInputs` and the `.tlog` files for future builds without actually modifying the `.vcxproj` file. Fixes: #20286
* add_custom_command: Target-dependent generator expression supportRaul Tambre2021-05-311-0/+5
| | | | | | | | | OUTPUT variant with a TARGET given to allow resolving target-based generator expressions wouldn't work because OUTPUT is resolved before generator targets are created, i.e. FindGeneratorTargetToUse() returns nullptr. This is a known limitation, see #21364. Implements #21336.
* Xcode: Add support of DEPFILE for add_custom_command, part 2Marc Chevrier2021-04-171-8/+0
| | | | | | This MR extend the support of 'DEPFILE' to buildsystem version 1. Issue: #20286
* Xcode: Add support of DEPFILE for add_custom_commandMarc Chevrier2021-04-151-10/+20
| | | | Issue: #20286
* Genex: add_custom_command: DEPFILE supports genexMarc Chevrier2021-04-121-1/+6
| | | | | | This facility is very useful for 'Ninja Multi-Config' and required as well for future support of DEPFILE in 'Xcode' and 'Visual Studio' generators (#20286).
* Help: Custom OUTPUT and BYPRODUCTS genexes cannot refer to targetsCraig Scott2021-03-251-2/+6
| | | Relates: #21364
* Help: Convert some genex names to explicit cross-referencesBrad King2021-02-051-2/+2
| | | | | | | | | Since commit c2dc7e0f53 (Help: Convert genex documentation to sphinx domain objects, 2021-01-15) we can use `:genex:` cross-references to link to named generator expressions. Update some places to do this. This is meant to demonstrate the capability, not as a comprehensive sweep.
* Makefiles: Add support of DEPFILE for add_custom_commandMarc Chevrier2020-12-231-3/+18
| | | | | Issue: #20286 Fixes: #21415
* Ninja Multi-Config: Add support for cross-config custom commandsKyle Edwards2020-12-151-0/+9
| | | | Co-Author: Brad King <brad.king@kitware.com>
* Help: Clarify version adding add_custom_{command,target} OUTPUT genex supportBrad King2020-12-151-32/+36
| | | | | | | Update the documentation added by commit c257c25419 (add_custom_{command,target}: Add genex support to OUTPUT and BYPRODUCTS, 2020-10-19) to use sphinx markup instead of prose to specify the version in which the feature was added.
* add_custom_{command,target}: Add genex support to OUTPUT and BYPRODUCTSBrad King2020-12-111-0/+48
| | | | | | | | | Move rejection of `#`, `<`, and `>` characters in outputs and byproducts to a generate-time check. This removes the front-end check that disallowed generator expressions. The generators have already been updated to handle them. Fixes: #12877
* Help: Add examples to add_custom_command reference documentationBrad King2020-12-101-0/+38
|
* Help: Add `.. versionadded` directives to commands documentationNikita Nemkin2020-11-091-11/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Ninja: Transform DEPFILEs with policy CMP0116Kyle Edwards2020-10-131-0/+5
| | | | Fixes: #21267
* GenEx: Remove unneeded dependencies from target info queriesRobert Maynard2020-09-011-7/+16
| | | | | | | | | | Only generate a graph dependency between a custom command and a target when the custom command queries for the file path of an artifact of the target. This makes generator expressions such as `TARGET_FILE_DIR` behave the same way as `TARGET_PROPERTY` which never generated a graph dependency.
* Help: Expand discussion of GENERATED / BYPRODUCTSFeRD (Frank Dana)2020-03-121-0/+3
| | | | | | | | - Mention the Makefile Generators' `make clean` removal in the BYPRODUCTS section of add_custom_command and add_custom_target - Expand the GENERATED property docs' description of which files will be marked with the property, and of what it implies (including `make clean` removal)
* Help: Clarify add_custom_command DEPENDS conversion to file pathsBrad King2020-03-061-14/+30
| | | | | | | | | | | | | | | In commit f5126badd8 (add_custom_command: convert DEPENDS path arguments to absolute paths, 2019-12-18, v3.17.0-rc1~263^2) we updated the documentation to describe the behavior introduced by that commit. However, the behavior was removed again by commit fd0ba705ce (add_custom_command: check if a relative path should be an in-source path, 2020-01-09, v3.17.0-rc1~141^2~4) without updating the documentation. Update the documentation again to describe the behavior as of the latter commit. Spell out the steps that `cmLocalGenerator::GetRealDependency` and `cmTargetTraceDependencies::IsUtility` use to add file-level and target-level dependencies.
* add_custom_command: convert DEPENDS path arguments to absolute pathsBen Boeckel2019-12-181-3/+5
| | | | | | | This is only done if they are "obviously" paths in that they contain a directory separator. Fixes: #17111
* Help: Both add_custom_command signatures support COMMAND_EXPAND_LISTSMarc Aldorasi2019-11-111-1/+2
|
* Help: Clarify how target names are handled in custom commands/targetsCraig Scott2019-10-051-16/+24
| | | Fixes: #19771
* Depend: Hook up automatic target-level dependencies via byproductsDaniel Eiband2019-09-121-3/+3
| | | | | | | | Target-level dependencies to utility targets are added from another target if the other target requires a byproduct of the utility target or if it requires a byproduct of PRE_BUILD, PRE_LINK, or POST_BUILD build events of a target. Issue: #19005
* Support job pools in custom commands and targetsRosen Matev2019-05-141-0/+8
| | | | | | | | | | Provide a way for custom commands and targets to set the pool variable of the ninja build statement. Setting `JOB_POOL` is not compatible with `USES_TERMINAL`, which implies the `console` pool. The option is silently ignored with other generators. Closes: #18483
* Help: Apply syntax highlighting to project commandsJoachim Wuttke (o)2018-10-251-2/+4
| | | | | | * Replace most "::" by ".. code-block:: cmake" * Header sentence in imperative voice, detailed command description in present tense.
* add_custom_{command,target}: WORKING_DIRECTORY generator expressionsJon Chronopoulos2018-09-281-0/+3
| | | | | | | This teaches add_custom_command and add_custom_target WORKING_DIRECTORY about generator expressions Fixes: #14089
* Help: Clarify add_custom_command build event execution orderBrad King2018-05-021-4/+3
| | | | Fixes: #17949
* Drop Visual Studio 8 2005 generatorBrad King2018-04-021-1/+1
| | | | This generator has been deprecated since CMake 3.9. Remove it.
* Help: Improved MAIN_DEPENDENCY documentation of add_custom_command()Christoph Ruediger2018-01-161-2/+4
|
* VS: only add custom command line if it is not emptyMichael Stürmer2017-09-041-0/+10
|
* Drop Visual Studio 7 .NET 2003 generatorBrad King2017-04-191-1/+1
| | | | This generator has been deprecated since CMake 3.6. Remove it.
* add_custom_{command,target}: Add COMMAND_EXPAND_LISTS optionEd Branch2017-01-141-1/+10
| | | | | | This option allows lists generated by generator expressions to be expanded. Closes: #15935
* add_custom_command: Add DEPFILE option for NinjaKulla Christoph2016-08-301-0/+7
| | | | | | | | Provide a way for custom commands to inform the ninja build tool about their implicit dependencies. For now simply make use of the option an error on other generators. Closes: #15479
* CustomCommandGenerator: Add support for CROSSCOMPILING_EMULATORJean-Christophe Fillion-Robin2016-05-091-2/+5
| | | | | | Teach the `add_custom_command` and `add_custom_target' commands to substitute argv0 with the crosscompiling emulator if it is a target with the `CROSSCOMPILING_EMULATOR` property set.
* Help: Clarify `add_custom_command(TARGET)` scope (#15681)Bartosz Kosiorek2016-01-281-2/+5
|
* Help: Reference TARGET_FILE genex in add_custom_command docs (#15605)Brad King2015-06-081-0/+3
| | | | | | | | | When documenting in the COMMAND option how to reference an executable, we previously only explicitly covered how to do it for argv[0] and left it to the reader to follow the reference to the generator expressions manual. Add explicit mention of the TARGET_FILE genex in this documentation since it will be a commonly used generator expression in this context.
* Help: Add some cross-linking.Stephen Kelly2015-02-041-1/+1
|
* Help: Document MAIN_DEPENDENCY limitation in add_custom_commandBrad King2014-12-161-1/+2
| | | | | Specify explicitly that at most one custom command may use a given source file as its main dependency.
* Add an option for explicit BYPRODUCTS of custom commands (#14963)Brad King2014-11-141-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A common idiom in CMake-based build systems is to have custom commands that generate files not listed explicitly as outputs so that these files do not have to be newer than the inputs. The file modification times of such "byproducts" are updated only when their content changes. Then other build rules can depend on the byproducts explicitly so that their dependents rebuild when the content of the original byproducts really does change. This "undeclared byproduct" approach is necessary for Makefile, VS, and Xcode build tools because if a byproduct were listed as an output of a rule then the rule would always rerun when the input is newer than the byproduct but the byproduct may never be updated. Ninja solves this problem by offering a 'restat' feature to check whether an output was really modified after running a rule and tracking the fact that it is up to date separately from its timestamp. However, Ninja also stats all dependencies up front and will only restat files that are listed as outputs of rules with the 'restat' option enabled. Therefore an undeclared byproduct that does not exist at the start of the build will be considered missing and the build will fail even if other dependencies would cause the byproduct to be available before its dependents build. CMake works around this limitation by adding 'phony' build rules for custom command dependencies in the build tree that do not have any explicit specification of what produces them. This is not optimal because it prevents Ninja from reporting an error when an input to a rule really is missing. A better approach is to allow projects to explicitly specify the byproducts of their custom commands so that no phony rules are needed for them. In order to work with the non-Ninja generators, the byproducts must be known separately from the outputs. Add a new "BYPRODUCTS" option to the add_custom_command and add_custom_target commands to specify byproducts explicitly. Teach the Ninja generator to specify byproducts as outputs of the custom commands. In the case of POST_BUILD, PRE_LINK, and PRE_BUILD events on targets that link, the byproducts must be specified as outputs of the link rule that runs the commands. Activate 'restat' for such rules so that Ninja knows it needs to check the byproducts, but not for link rules that have no byproducts.
* Add USES_TERMINAL option for custom commandsPeter Collingbourne2014-11-141-2/+9
| | | | | | Teach the add_custom_command and add_custom_target commands a new USES_TERMINAL option. Use it to tell the generator to give the command direct access to the terminal if possible.
* Help: Document add_custom_command marking outputs GENERATEDBrad King2014-11-141-0/+2
|
* Help: Suggest in add_custom_command how to create a script (#15112)Brad King2014-09-081-0/+3
|
* Help: Clarify add_custom_command multiple command behavior (#15112)Brad King2014-09-021-1/+2
| | | | | Explicitly say that the commands are not composed into a stateful script.
* Help: Document add_custom_command PRE_BUILD/PRE_LINK for exe/lib only (#15059)Brad King2014-08-051-0/+2
| | | | | | | State explicitly that the PRE_LINK mode is not for targets created by the add_custom_target command. The existing wording for PRE_BUILD being treated as PRE_LINK by non-VS generators will now imply this restriction for PRE_BUILD too.
* Help: Revise and format 'add_custom_command' docsBrad King2014-08-051-97/+122
| | | | | | Format the reStructuredText markup manually. Organize the command options into a definition list. Use inline markup to cross-reference related documents.
* Help: Remove stray content from 'add_custom_command' docsBrad King2014-08-051-24/+0
| | | | | Remove leftover generator expression documentation that is now in the cmake-generator-expressions(7) manual.
* add_custom_command: Evaluate generator expressions in DEPENDSStephen Kelly2014-03-201-0/+4
| | | | | | | Rely on evaluation in cmCustomCommandGenerator for the generators. When tracing target dependencies, depend on the union of dependencies for all configurations.
generated by cgit v0.12 at 2025-02-09 01:57:29 (GMT)