Provide options to fail without blocking or to block up to a timeout.
Provide options to specify the scope containing the lock so it can be
released automatically at the end of a function, file, or process.
Extend the RunCMake.file test with cases covering the file(LOCK) command
usage and error cases.
8a75c7ef Help: Document the export limitation of INTERFACE_SOURCES.
e1348056 Export: Disallow export of targets with INTERFACE_SOURCES
bb5905bb cmTarget: Don't allow relative paths in INTERFACE_SOURCES
This can be allowed in the next release, but it needs to have some
features present and tested such as
* Ensuring that relative paths do not appear in the generated property.
* Ensuring that paths to the source or build directories do not appear.
* Generating a check in the file for CMake 3.1 or later so that the
resulting property will be consumed.
* Ensuring that any referenced targets are part of an export set and
generating a check for them.
* INSTALL_INTERFACE and BUILD_INTERFACE content.
All of these checks are already done for INTERFACE_INCLUDE_DIRECTORIES,
but it is too late to add them for INTERFACE_SOURCES for CMake 3.1.
As the checks introduce some new error conditions, it is better to
disallow exporting fully for this case and introduce proper error
conditions later instead of policies.
Follow the pattern of checks that are made for INTERFACE_INCLUDE_DIRECTORIES.
Existence is already checked by cmSourceFile::GetFullPath. Add a check
to disallow relative paths in source directories. Otherwise code such as
target_sources(lib1 INTERFACE foo.cpp)
would fail if consumed by a target in a different directory.
Unlike the INTERFACE_INCLUDE_DIRECTORIES behavior, we don't care whether
the entry comes from an IMPORTED target or not. In the include directories
case, the directory for a non-imported target might not exist yet but
might be created. In the sources case, a file which does not yet
exist in the filesystem must be explicitly marked with the GENERATED
property.
Adjust existing tests and add a new test for the error.
Extend the write_compiler_detection_header interface to allow
specifying a location for supplementary files, and getting the
list of resulting files as a variable.
Re-run if the input file changes or if the output file is removed.
This only works with the Makefile generators currently. The limitation
of the Ninja generator is tracked as issue #15256. The IDE
generators will need larger refactoring as they currently rely on
being able to determine the depends and output files at the start of
generate-time, which is too early for the file(GENERATE) case.
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.
The evaluation files must be known before cmTargetTraceDependencies
attempts to find them, but we must actually generate the files after
cmTargetTraceDependencies, as that can add to target SOURCES. The
limitation is that the generated output name must not depend on the
SOURCES of a target if the generated file is used by that target.
Mark the output files as GENERATED so that trace dependencies does
not expect them to already exist in the filesystem.
Move the invokation of ForceLinkerLanguage in the Generate logic
to after the generated file names are known. ForceLinkerLanguage
tries to determine the sources of a target (in order to determine
an already-known language) and otherwise fails to get information
about the generated file.
Test that the output of file(GENERATE) can be used as a target source
file and that accessing the target SOURCES in the name of the output
file is an error. Accessing the TARGET_OBJECTS would be a similar
error if it was legal to use that generator expression in this
context. That is not currently possible and is a different error
condition, so test the current error output as a reminder to change
the expected output if that becomes possible in the future. Test
that generated rule files resulting from cmTargetTraceDependencies
appear in the SOURCES generated in the output file.
1531df2b configure_file: Warn about unknown arguments
4abbb140 Qt4: Fix configure_file call to use COPYONLY, not COPY_ONLY
bd7ba8e2 KWSys: Fix configure_file call to use COPYONLY, not COPY_ONLY
e9282782 Help: Fix configure_file call to use COPYONLY, not COPY_ONLY
Extend the RunCMake.configure_file test with a case covering possible
common typos of the COPYONLY option.
Reported-by: Iosif Neitzke <iosif.neitzke@gmail.com>
609037f4 ExternalProject: Add unit tests for CMAKE_CACHE_DEFAULT_ARGS
98cdb658 ExternalProject: Add CMAKE_CACHE_DEFAULT_ARGS arguments
36cf8a1e Tests/Tutorial: Fix when USE_MYMATH is OFF
d1b62185 Merge branch 'parent-scope-tests' into variable-pull-failure
5f414cef Revert "cmDefinitions: Don't store parent lookups"
e0c0b1ac test: add a test for PARENT_SCOPE with multiple scopes
064c415d test: add test for PARENT_SCOPE behavior
* parent-scope-tests:
test: add a test for PARENT_SCOPE with multiple scopes
test: add test for PARENT_SCOPE behavior
Conflicts:
Tests/RunCMake/set/RunCMakeTest.cmake
In the case of:
-DCACHE_VARS=-DEXTERNAL_PROJECT_CMAKE_ARG:BOOL=TRUE
the variable is parsed out as:
CACHE_VARS=-DEXTERNAL_PROJECT_CMAKE_ARG
because the parser allows '=' in the variable name. Disallow such a name
on the command line.
Given that you have a foobar that identifies itself as 1.2.3 from now on a
find_package(foobar 1.2 EXACT)
will succeed, as 1.2.3 will now be considered as being 1.2. Until now this was
only the case for version 1.2.0.
Unlike with Unix Makefiles generator modifying compiler paths was not
protected with Ninja generator. It was possible to modify them in the
cache without the expected effect on the generated solution. Also
activate corresponding tests with Ninja.
be6a555d Tests: Test setting a generator platform in a toolchain file
d506fee8 Tests: Use -A option to pass generator platform selection
11c9ddd6 ExternalProject: Use -A option to pass generator platform
29bd843e CTest: Use -A option to pass generator platform selection
eb7d8156 cmake: Add -A option to specify a generator platform
858d5a0b Fix if() checks of CMAKE_SYSTEM_NAME on Cygwin
e177e7af FPHSA: Avoid if() dereferencing of quoted variable
425acc52 cmcurl: Use if(DEFINED) to simplify conditions
cede5cbd libarchive: Avoid depending on if() to dereference a quoted variable
2d97178b FindGTK2: Avoid depending on if() to dereference a quoted variable
0b12815d Modules/Test*.cmake: Use if(DEFINED) to simplify conditions
188a1f23 If: Introduce policy CMP0054 - don't dereference quoted variables in if()
b900c1cc If: Extract cmConditionEvaluator from if() implementation
Define the 'cmake -A' option to set CMAKE_GENERATOR_PLATFORM
without having to spell out the whole variable name. We choose
the name '-A' for "platform" because '-P' is already taken, and
in the common use case the "platform" is actually an architecture
(e.g. x64).
Teach the RunCMake test infrastructure to use -A to pass the generator
platform. Extend the RunCMake.GeneratorPlatform test with a case to
verify that the -A option cannot be repeated.
For VS generator names that do not specify the platform name, read
CMAKE_GENERATOR_PLATFORM to get it.
Extend the RunCMake.GeneratorPlatform test with a case covering
use of the x64 platform when the test generator is a Visual Studio
generator whose name does not specify a platform.
Reject the option by default. It will be implemented on a per-generator
basis. Pass the setting into try_compile project generation. Add cache
entry CMAKE_GENERATOR_PLATFORM and associated variable documentation to
hold the value persistently.
Add a RunCMake.GeneratorPlatform test to cover basic use cases for the
option. Verify that CMAKE_GENERATOR_PLATFORM is empty by default, and
that it is rejected when the generator does not support a user setting.
The lexer changes in commit v3.0.0-rc1~495^2 (Add Lua-style long
brackets and long comments to CMake language, 2013-08-06) accidentally
left out matching '[' as a single character in an unquoted argument.
Add a lexer rule to match it and extend the RunCMake.Syntax test to
cover this case.
Brad King
Ben Boeckel
Ruslan Baratov
Gregor Jasny
Stephen Kelly
Peter Collingbourne
Daniele E. Domenichelli
Rolf Eike Beer
Sylvain Joubert
Nils Gladitz