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.
f7e33820 Add release notes for export-interface-source-files.
6da65b39 Allow export of targets with INTERFACE_SOURCES.
736bcb96 Tests: Move IfacePaths test stderr files.
d9f8390d Tests: Run IfacePaths tests with a parameter.
cc152094 Tests: Split part of include_directories test to a generic location.
c0d8e715 RunCMake: Allow specifying the stderr file for a test.
68d29f51 RunCMake: Allow specifying the directory to run tests in.
1c3918ff RunCMake: Remove unneeded files.
0f870234 Merge branch 'backport-no-global-setlocale' into no-global-setlocale
cd408d93 Add setlocale() calls around use of libarchive APIs (#14934, #15377)
87be2e14 Do not call setlocale() globally in CMake applications (#15377)
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.
Revert the changes made by commit v3.1.0-rc1~406^2~1 (Encoding: Add
setlocale() to applications, 2014-05-30) and commit v3.1.0-rc1~406^2
(Encoding: Change to only set LC_CTYPE, 2014-06-11), and other setlocale
calls added later in their spirit. CMake has not been taught how to
deal with non-C locales everywhere. We do not define any functionality
for character conversions for non-ASCII strings. Another solution will
be needed to address the original problem motivating addition of
setlocale() calls.
This bug caused c_function_prototypes to not be recorded at configure
time when compiling with -std=gnu99 or similar. In the case of feature
recording, that was not a problem, because the logic in
CMakeDetermineCompileFeatures.cmake currently assumes that a feature
present for an earlier standard is present for a later standard.
However, the detection strings are also used in WriteCompilerDetectionHeader,
so the feature macro has been defined to '0' when using a later language
dialect.
Fix that by not checking the existence of the __STDC_VERSION__ macro at
all when detecting C90 features.
809a5a5e Help: Add notes for topic 'CTestCoverageCollectGCOV-refinements'
03c0812c CTestCoverageCollectGCOV: Fix handling of international characters
8caa4e72 CTestCoverageCollectGCOV: Add test case
5c828cc8 CTestCoverageCollectGCOV: Allow custom flags to gcov
30cb628e CTestCoverageCollectGCOV: Fix handling of large file counts
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.
ab9fa54d Xcode: Switch to internal CMAKE_MAKE_PROGRAM lookup by generator (#15324)
11e2e6ca Xcode: Select make program at build time
e4055a61 Xcode: Add internal API to find xcodebuild
The "cmakexbuild" wrapper is not needed for Xcode 4 and above, and the
path to it may change when CMake moves. Avoid storing a specific path
to a build program in CMakeCache.txt and instead compute the value for
CMAKE_MAKE_PROGRAM on demand. However, if a user does set the value
explicitly then honor it.
This does for Xcode what commit v3.0.0-rc1~260^2~4 (VS: Switch to
internal CMAKE_MAKE_PROGRAM lookup by generators, 2013-11-15) did for
Visual Studio generators.
Custom command path normalization added in commit v3.1.0-rc1~471^2
(add_custom_command: Normalize OUTPUT and DEPENDS paths, 2014-05-28)
broke use of OBJECT_DEPENDS to bring in custom commands because the
latter paths were not normalized too. Normalize them and add a test
case.
Reported-by: Daniel v. Gerpen
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.
Zack Galbreath
Brad King
Stephen Kelly
Bill Hoffman
Robert Maynard
Domen Vrankar
Robert Goulet
Justin Borodinsky