| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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
|
| |\
| |
| |
| |
| |
| |
| | |
36921d2d23 Xcode: Fix custom command work-dir placeholders in "new build system"
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5527
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The placeholders for `CONFIGURATION` and `EFFECTIVE_PLATFORM_NAME` need
to be handled in the `WORKING_DIRECTORY` of custom commands just as we
already do for the `COMMAND`.
Fixes: #21483
|
| |/
|
|
|
|
|
| |
Since commit 777ceaea94 (cmMakefile: Delay custom command creation,
2019-10-17, v3.17.0-rc1~352^2) we process custom command declarations
at generate time. This includes the append-to-non-existing-command
check, so we do not need it at configure time.
|
| | |
|
| |
|
|
|
| |
Use the output checks for byproducts of add_custom_command also for byproducts
of add_custom_target.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Add test for collapsing of full paths in byproducts and additional tests for
the GENERATED source file properties set by add_custom_command and
add_custom_target with relative paths.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a custom command is assigned to multiple targets, generate the build
rule only in the least-dependent `.vcxproj` file. Otherwise MSBuild
will run the command on the first build of a dependent target even if
its dependencies already brought the command up to date (in order to
populates its build log).
Generate targets in least-to-most-dependent order, and assign a custom
command to the least dependent target.
Added cmLocalVisualStudio10Generator::GenerateTargetsDepthFirst to call
cmVisualStudio10TargetGenerator::Generate in least-dependent order.
Moved SourcesVisited from cmVisualStudio10TargetGenerator to
cmLocalVisualStudio10Generator to avoid attaching a custom command to
multiple targets among the local generator.
Fixes: #16767
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I otherwise get:
Expected stderr to match:
expect-err> CMake Error at AppendNotOutput.cmake:1 \(add_custom_command\):
expect-err> add_custom_command given APPEND option with output.*
expect-err> which is not already a custom command output.
expect-err> Call Stack \(most recent call first\):
expect-err> CMakeLists.txt:3 \(include\)
Actual stderr:
actual-err> CMake Error at AppendNotOutput.cmake:1 (add_custom_command):
actual-err> add_custom_command given APPEND option with output
actual-err> "/home/stephen/dev/src/cmake/with
actual-err> space/Tests/RunCMake/add_custom_command/AppendNotOutput-build/out" which is
actual-err> not already a custom command output.
actual-err> Call Stack (most recent call first):
actual-err> CMakeLists.txt:3 (include)
Using a specific line for paths is a style already used elsewhere for
the same reason, such as CMP0041 output.
|
| |
|
|
|
|
|
|
| |
The add_custom_command(TARGET) signature only works for targets defined
in the current directory. Clarify this in the error message when the
target exists but was defined elsewhere.
Inspired-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
|
|
Add RunCMake.add_custom_command and RunCMake.add_custom_target tests to
cover the error messages for these commands.
|
