But only do so if the depfile is not specified as an output of the
command. Otherwise the command will out-of-date itself as `ninja`
deletes depfiles that it incorporates into the database and a missing
output will cause the command to run again.
This requires knowing when a generated header is public, which we can
model using file sets. Add policy CMP0154 to treat generated sources
as private by default in targets with file sets. Generated public
headers can be specified in public file sets.
Fixes: #24959
Issue: #15555
e588d29eaf Help: add_custom_command(TARGET) does not support USES_TERMINAL
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: William Jones <william.luke.jones@gmail.com>
Merge-request: !8602
Add CMake variable `CMAKE_ADD_CUSTOM_COMMAND_DEPENDS_EXPLICIT_ONLY` to enable
option `DEPENDS_EXPLICIT_ONLY` on all uses of `add_custom_command`.
Fixes: #17097
Add option `DEPENDS_EXPLICIT_ONLY` to `add_custom_command` to indicate
that implicit dependencies coming from users of the output are not
needed, and only consider dependencies explicitly specified in the
custom command.
Fixes: #17097
The "In makefile terms" explanation is left from very early days of
CMake to help developers migrating from hand-written makefiles.
These days it is often misinterpreted, particularly in the context
of multiple `add_custom_command` calls, to mean that we generate a
single Makefile containing rules for all custom commands. This
leads to an incorrect mental model of the expressed build system.
The actual generated build system may spread the rules across multiple
targets that do not see the each other's file-level rules, which makes
target-level dependencies important too.
Evaluate and expand generator expressions in the `COMMENT` argument of
the `add_custom_command()` and `add_custom_target()` commands.
This allows to include generator expressions, e.g. a targets location
$<TARGET_...> or the current configuration $<CONFIG>, in the build-time
messages.
Fixes#22507
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
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.
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
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.
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).
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.
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.
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
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
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.
- 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)
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.
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
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
