kolan
/
CMake
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
CMake/Tests/RunCMake/add_custom_target/RunCMakeTest.cmake

21 lines
653 B
CMake
Raw Normal View History

Tests: Test add_custom_command and add_custom_target error cases Add RunCMake.add_custom_command and RunCMake.add_custom_target tests to cover the error messages for these commands.
2014-11-13 20:46:49 +03:00
include(RunCMake)
run_cmake(NoArguments)
run_cmake(BadTargetName)
Add an option for explicit BYPRODUCTS of custom commands (#14963) 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.
2014-11-14 02:54:52 +03:00
run_cmake(ByproductsNoCommand)
Add USES_TERMINAL option for custom commands 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.
2014-11-05 23:37:52 +03:00
run_cmake(UsesTerminalNoCommand)
Ninja: Fix inter-target order-only dependencies of custom commands Custom command dependencies are followed for each target's source files and add their transitive closure to the corresponding target. This means that when a custom command in one target has a dependency on a custom command in another target, both will appear in the dependent target's sources. For the Makefile, VS IDE, and Xcode generators this is not a problem because each target gets its own independent build system that is evaluated in target dependency order. By the time the dependent target is built the custom command that belongs to one of its dependencies will already have been brought up to date. For the Ninja generator we need to generate a monolithic build system covering all targets so we can have only one copy of a custom command. This means that we need to reconcile the target-level ordering dependencies from its appearance in multiple targets to include only the least-dependent common set. This is done by computing the set intersection of the dependencies of all the targets containing a custom command. However, we previously included only the direct dependencies so any target-level dependency not directly added to all targets into which a custom command propagates was discarded. Fix this by computing the transitive closure of dependencies for each target and then intersecting those sets. That will get the common set of dependencies. Also add a test to cover a case in which the incorrectly dropped target ordering dependencies would fail.
2016-07-20 16:32:32 +03:00
function(run_TargetOrder)
# Use a single build tree for a few tests without cleaning.
set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/TargetOrder-build)
set(RunCMake_TEST_NO_CLEAN 1)
file(REMOVE_RECURSE "${RunCMake_TEST_BINARY_DIR}")
file(MAKE_DIRECTORY "${RunCMake_TEST_BINARY_DIR}")
run_cmake(TargetOrder)
if(RunCMake_GENERATOR STREQUAL "Ninja")
set(build_flags -j 1 -v)
endif()
run_cmake_command(TargetOrder-build ${CMAKE_COMMAND} --build . -- ${build_flags})
endfunction()
run_TargetOrder()