Move the test cases from Tests/CMakeTests/ConfigureFileTest.cmake.in
over to use the RunCMake.configure_file infrastructure. This does much
more robust verification of CMake output for each test case, and would
have caught the regression fixed in our parent commit.
A more-specific error message is always displayed earlier in the
output if any real error occurred. This final summary message
is distracting to readers searching through the output for the
word "error". Simply drop it.
Allow URL templates to contain a %(algo:<key>) placeholder that is
replaced by mapping the canonical hash algorithm name through a map
defined by the <key>.
Extend the Module.ExternalData test to cover the behavior.
Extend the RunCMake.ExternalData test to cover error cases.
e2b9e7f7 Tests: Drop unnecessary stderr matching from RunCMake.ctest_memcheck
7ce9f6e2 Tests: Teach RunCMake to tolerate 'Error kstat returned' lines in test output
69de0f7e Tests: Teach RunCMake to tolerate Guard Malloc lines in test output
57f2aa7c Tests: Teach RunCMake to tolerate BullseyeCoverage lines in test output
b04c8ec3 Tests: Match curl error in RunCMake.ctest_submit FailDrop-* cases
1d82105e Tests: Rename RunCMake.{CTestMemcheck => ctest_memcheck}
d7662141 Tests: Rename RunCMake.{CTestSubmit => ctest_submit}
9b50388b Tests: Split RunCTest helper out of RunCMake.CTest(Submit|Memcheck)
76e7c22b Tests: Rename RunCMake.CTestMemcheck internals to match CTestSubmit
Otherwise find_library is unable to lookup the XCTest framework which
is not located in the SDK serach path:
In the 10.10 SDK the SDK frameworks are located here:
$DEVELOPER_DIR/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks
whereas the Platform SDKs are located here:
$DEVELOPER_DIR/Platforms/MacOSX.platform/Developer/Library/Frameworks
Signed-off-by: Gregor Jasny <gjasny@googlemail.com>
If a feature is added multiple times via ADD_FEATURE_INFO it should
appear only once in FEATURE_SUMMARY.
Signed-off-by: Gregor Jasny <gjasny@googlemail.com>
bb9d71b4 Replace loops with algorithms.
4afe6c26 cmAlgorithms: Add cmReverseRange adaptor.
a3a0a8c2 cmAlgorithms: Add cmFindNot algorithm.
8c74a41f cmRST: Replace two erase with a rotate and larger erase.
61fe1919 cmAlgorithms: Update concept requirement to FowardIterator
09d6125b cmAlgorithms: Move cmRotate out of 'implementation detail' namespace.
8ed6ecac cmRST: Move two algorithms beside each other.
dfe49c20 cmRST: Use std::min where appropriate.
21b0654a cmGlobalGenerator: Convert set insert algorithm to vector algorithms.
416df93a Convert some raw loops to cmWrap.
37b88d34 cmAlgorithms: Add cmWrap.
a2818093 Use cmJoin where possible.
76207b08 cmCacheManager: Replace loop with algorithm.
60c3bb73 cmGlobalGenerator: Replace loop with algorithm.
05fec779 cmTarget: Port loop to algorithm.
9c225767 cmGlobalGenerator: Replace set::insert algorithm with cmRemoveDuplicates.
...
The Dummy*-stderr.txt files were needed only to match platform-specific
memcheck tooling output and verify that stderr is otherwise empty. Now
that the RunCMake infrastructure knows how to strip such lines before
matching, we can simply drop these files and use the default empty
string match.
When RunCMake tests run on Solaris, the output may contain unexpected
lines of the form "Error kstat returned...". These lines are printed by
SystemInformationImplementation::RunProcess when called from
SystemInformationImplementation::ParseValueFromKStat (see issue #12066).
Until someone investigates why kstat returns values outside the range it
documents, simply remove such lines from the actual output before
matching it against the expected output.
When RunCMake tests run under Xcode Guard Malloc, Guard Malloc may add
lines of the form "<tool>(<pid>) malloc:..." to the output. Remove such
lines from the actual output before matching it against the expected
output.
When RunCMake tests run under dynamic analysis, Bullseye may add lines
of the form "BullseyeCoverage..." to the output. Remove such lines from the
actual output before matching it against the expected output.
The find_package command already knows how to compute installation
prefixes from PATH. Use the same approach to establish prefixes for
find_library, find_file, and find_path to use to look in directories
like "<prefix>/lib[/<arch>]" and "<prefix>/include" for libraries and
headers. This will reduce the amount of configuration end users need to
do to establish a work environment rooted under a specific prefix.
Several tests use slight variations of the same logic to enable CPack
RPM tests. Consolidate this logic into one check before any tests are
added. Look for 'rpmbuild' only on Linux and only when the test build
tree does not have spaces in the path. In particular, this will make
the result available in time for the RunCMake.CPackRPM test to be
activated even if CMake is configured exactly once.
This will allow per-config destinations for targets in EXPORT sets.
Using multiple install(TARGETS) with separate CONFIGURATIONS is
rejected as a target appearing more than once in an export set.
Now instead one can write
install(TARGETS foo EXPORT exp DESTINATION lib/$<CONFIG>)
to get a single logical membership of the target in the export set
while still having a per-config destination.
The moved tests are related to paths in INTERFACE_INCLUDE_DIRECTORIES
in general, and when exporting, and covering cases of the install
location being within the build or source prefix etc. Other build
properties containing paths should have similar tests, so this
allows some parameterization while keeping the preparation of the
various directory structures.
Define an empty string in CMAKE_<LANG>_STANDARD_DEFAULT to mean that
the toolchain has no notion of lanuage standard levels. In this case
the <LANG>_STANDARD[_REQUIRED] properties will have no effect.
Update the RunCMake.CompileFeatures test to exclude the
LinkImplementationFeatureCycle test when there is no standard default.
It can never fail because no use of specific features will adjust the
CXX_STANDARD level required for any target since the standard levels
have no meaning in this case.
With the Makefile generators we expect that touching or modifying the
input file of a configure_file, or removing its output, will cause CMake
to re-run on the next build. Extend the RunCMake.configure_file test
with a case covering this. Also check that CMake does not re-run if
nothing has changed.
With the Makefile and Ninja generators we expect that touching the input
source file for a try_compile will cause CMake to re-run on the next
build. Extend the RunCMake.try_compile test with a case covering this.
Also check that CMake does not re-run if nothing has changed.
Read file names from the lines of a specified file. Reject input lines
starting in '-' to leave room for option parsing to be added later. Add
just '--add-file=' now to allow files starting in '-' to be specified.
d0adcccb try_run: Add tests for LINK_LIBRARIES with mock libraries.
223c5cb7 try_run: Add test for bad link libraries.
e2b1f058 try_run: Add support for LINK_LIBRARIES option.
Most functionality is already implemented in Source/cmCoreTryCompile.{h,cxx}.
Document and improve argument parsing.
This functionality is already being used by a number of modules, like
CheckCSourceCompiles.cmake, but it is not documented.
f3e0b6f1 CTestCoverageCollectGCOV: Add module to run gcov
6dd980e0 ctest_submit: Make CDASH_UPLOAD mode arguments more strict
5dc33f89 ctest_submit: Add CDASH_UPLOAD mode to upload files to CDash
When curl is given a URL of the form '<something>://' it tries to
resolve '<something>' as a host name. If the host happens to exist and
have a server then the drop might actually appear to work. Instead use
an explicit '-no-site-' host to ensure it cannot connect.
Reported-by: Gilles Khouzam <Gilles.Khouzam@microsoft.com>
Add an option to set the mtime of entries in a tarball so that one can
create a tarball with a consistent content hash (e.g. MD5) for a given
set of files regardless of their current timestamps on disk. This will
be useful for submission of tarballs to CDash, which tracks content
hashes to avoid duplication.
Inspired-by: Bill Hoffman <bill.hoffman@kitware.com>
004e1540 Features: Record for GNU 4.4.
2a5ca650 Features: Wrap failure-test in UNIX condition.
1ae2c6b2 Features: Blacklist cxx_constexpr test for GNU 4.5.
c66e3317 Features: Use a more-common feature in cycle-test.
c43a6dc5 Features: Update comment in test to match the code.
78259135 Features: Test presence of cxx_auto_type with genex.
7b9fc88b Features: Remove outdated comment.
Replace the TODO comment with calls to run_ctest_submit_FailDrop. For
now leave curl errors out of expected stderr. They can be ported over
from CTestTestFailedSubmit-* tests later.
Cover command invocation argument errors. Prepare infrastructure
to cover failed 'drop' cases, but do not cover them yet because
we need to collect error messages from each platform.
We require that the $<$<COMPILE_FEATURES:cxx_feature>:empty2> generates
a '1' when CXX11 is enabled. GNU 4.4 does not support cxx_nullptr, but
does support cxx_auto_type.
770ba876 Help: Add notes for topic 'GNU-4.6-compile-features'
b15c008f Features: Record for GNU 4.6.
f13a2eb1 Features: Adjust the RunCMake test to use more-common features.
1f19ac4d Features: Adjust cxx_variadic_templates unit test for GNU < 4.7.
0798d1e5 Features: Extend the generalized_initializers test for GNU < 4.7.
938bd94e Features: Test __GXX_EXPERIMENTAL_CXX0X__ macro for GNU < 4.7 compatibility.
462c630b Features: Don't test __cplusplus value for CXX98 on GNU.
222ec86f Features: Test an old value of __STDC_VERSION__ for GNU < 4.7 compatibility.
6e909035 Features: Record C/CXX dialect flags for GNU 4.6.
bfc995cc Features: Remove wrong content from else() condition.
1532b921 Features: Make cxx_noexcept available from GNU 4.6.
1f4649e6 Features: Update the default_dialect test for old GNU-like compilers.
a60027a6 Features: Ensure appropriate return value from feature test macros.
Add support for a special URL template to map the fetch operation
to a project-specified .cmake script insead of using file(DOWNLOAD).
Extend the Module.ExternalData test to cover the behavior.
Extend the RunCMake.ExternalData test to cover error cases.
The second hunk of commit 07d1f6fc (Features: Properly evaluate if the
compiler supports cxx_final, 2014-12-31) was a workaround for a bug in
the COMPILE_FEATURES generator expression that caused it never to return
0. Revert the workaround so we can fix the bug instead.
Revert commits:
2d738ce3 Help: Add notes for topic 'feature_record_msvc'
f73718c9 Features: Enable writing of MSVC compiler feature header.
64c30bdc Features: Record for MSVC C++ 2015 and MSVC C 2010-2015.
225c0ef8 Features: Record for MSVC 2010-2013.
This topic was merged to master prematurely, so remove it.
Commit v3.1.0-rc1~297^2~5 (cmTarget: Drop 'head' argument from
GetSourceFiles, 2014-07-10) exposed a dormant bug in source file computation,
causing the test case to regress. After that commit, the source file
computation and caching finds an existing container of source files. Prior to
that patch, the GetSourceFiles method was called with either a null pointer
for the head cmTarget, or it was called with the this pointer. The
processSources method is eventually called, which normalizes the difference
between the null pointer and the this pointer for the head target. However,
the cache key depends on the actual pre-normalized pointer. The change in
that commit caused the entry to be found in the cache where it was not before,
which resulted in incorrect behavior.
Prior to that commit, the test case also fails if the GetSourceFiles overload
taking a vector<cmSourceFile*> is changed to normalize the head target at
the beginning of the method:
cmTarget const* head = head_ ? head_ : this;
Such a construct was correctly used in other locations where similar caching
was in place, before being removed in commit v3.1.0-rc1~310^2~25 (cmTarget:
Remove 'head' argument from GetLinkInformation, 2014-06-12), but is not
neccessary anymore.
Commit v3.1.0-rc1~674^2~2 (cmTarget: Cache the cmSourceFiles in
GetSourceFiles., 2014-04-05) introduced the caching, but fails the test case
for an unrelated reason. That unrelated error was introduced in
commit v3.1.0-rc1~688^2~5 (cmTarget: Allow any generator expression in
SOURCES property., 2014-03-18) and fixed in
commit v3.1.0-rc1~561^2~1 (cmTarget: Fix listing of source files at
configure-time., 2014-04-13).
All commits which fail the test case in the testable way do so when such a
cached version of the source files is found and returned at generate
time. In the test case, the cached content is populated at configure-time
through the use of the deprecated LOCATION property with CMP0026 OLD. The
cached content is an empty container for the bar target in the test case,
because its source file 'foo.cpp.o' is not known until generate-time. That
means that no source files are available to compute the link language and
the reported error is issued.
The actual problem is that the SourceFilesMap should be cleared after
configure time by cmTarget::ClearLinkMaps. Clear it there now.
2d738ce3 Help: Add notes for topic 'feature_record_msvc'
f73718c9 Features: Enable writing of MSVC compiler feature header.
64c30bdc Features: Record for MSVC C++ 2015 and MSVC C 2010-2015.
225c0ef8 Features: Record for MSVC 2010-2013.
a15675ef Features: Quote all compiler names when comparing with COMPILER_ID
07d1f6fc Features: Properly evaluate if the compiler supports cxx_final.
6296192d Features: Add a comment explaining part of test.
c13656e7 Features: Test nullptr as a side-effect activation of static_assert.
3e34e833 Features: Test feature propagation with more-common features.
b3e86f4e Features: Test an expectation of whether OVERRIDE_CONTROL is expected
Notes:
VS2015 and above are the only MSVC versions to support cxx_final, so remove
usages from the tests, and instead only test for cxx_override.
VS2012 and above to conform to cxx_decltype_incomplete_return_types
proposal, but without support for auto return types the dcl.type.simple
example in the proposal doesn't compile.
VS2013 and above to conform to the updated cxx_contextual_conversions proposal,
but VS2010 and above pass the test.
Compilers such as MSVC have no explicit flags to enable C++11 mode,
it just is always on. So only run the link tests with compilers that require
a flag to specify the language version.
Previously we expanded HAVE_FINAL to determine what the copied_file number
would be, but when we don't have cxx_final than HAVE_FINAL is not defined.
What we really want is to use expected_result.
For complex*, CustomCommand and OutDir tests, non-ascii paths
are avoided in test code by using relative paths, and setting
the working when running the test. This also avoids the
need to internationalize the test code.
For RunCMake.GeneratorExpression, use a UTF-8 encoding in
file(STRINGS) to retrieve the compiled absolute path correctly.
Expect tests to specify stderr content if it is present.
Fix the CMP0019 test, which has only been testing the WARN status
until now. Specify in the CommandLine and FPHSA tests that content
is at least one character.
Set policies in the Language and CheckModules tests, which have empty
test output, modulo unrelated policies on some platforms.
Mark the generated source file with the GENERATED property explicitly
since it is not marked automatically as the output of any custom
command. Mark both the 0 and 1 variants so it works no matter the
outcome of the generator expression.
The CTestTestMemcheck test cases all try to check the ctest output with
a regular expression. They fail intermittently due to ordering of the
portions of the output that come from stdout and stderr being mixed.
Convert all the test cases to use the RunCMake infrastructure to match
stdout and stderr separately.
We use cmGlobalGenerator::GetDirectoryContent to avoid repeating
directory listings. However, GetDirectoryContent loads content from
disk at most once. This breaks find_library calls that occur when disk
content has changed since preceding find_library calls.
Teach cmGlobalGenerator::GetDirectoryContent to save the directory
modification time when content is loaded and re-load content if it
changes.
Create a RunCMake.find_library test with a case covering this.
Copy CMAKE_EXE_LINKER_FLAGS into the test project generated by
try_compile, just like we already copy CMAKE_<LANG>_FLAGS.
Add CMake Policy CMP0056 to activate this behavior in a compatible way,
but do not warn by default when the policy is not set since it will
affect all try_compile calls.
Extend the RunCMake.try_compile test with a case covering this behavior
for each policy setting.
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
Brad King
Stephen Kelly
Nils Gladitz
Zack Galbreath
Gregor Jasny
Domen Vrankar
Justin Borodinsky
Matt McCormick
Ben Boeckel
Robert Maynard
Clinton Stimpson
Ruslan Baratov
Peter Collingbourne
Daniele E. Domenichelli
Rolf Eike Beer
Sylvain Joubert