2af18704fd Merge branch 'backport-3.16-link-libs-config-case'
3f976bf201 target_link_libraries: Fix regression in case of $<CONFIG> genex
5a95b5e091 target_link_libraries: Fix regression in case of $<CONFIG> genex
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4544
Since commit b8626261e9 (Precompile headers: Add methods to generate PCH
sources, 2019-07-13, v3.16.0-rc1~182^2~4) we look up source files for a
target using an upper-case configuration even though an original-case
name is sufficient. Since commit 36ded610af (PCH: Generate sources
during Compute step, 2019-10-05, v3.16.0-rc1~2^2) the source file lookup
is the first time we compute many on-demand structures that depend on
the configuration name. This caused the `$<CONFIG>` generator
expression to evaluate to the upper-case configuration name in some
cases where we used original-case before.
Fix this by switching the source file lookup to the original-case config
name. Add a test covering the symptom that led to the discovery of this
problem.
Fixes: #20517
PRE_TEST makes it possible to properly distinguish between test cases
that exist only in certain configurations.
In the new test scenario, debug tests are disabled in release builds,
and release tests are disabled in debug builds
when a multi config generator is used.
Note, this is a bit of a hack and *only* works for PRE_TEST mode.
POST_BUILD makes no attempt to get this right. It preserves the status quo
and you obtain the tests that were last discovered.
See further discussion in !4078
Ideally, the POST_BUILD behavior could be fixed
by using generator expressions in OUTPUT and BYPRODUCT expressions.
Then you could do something like:
set(ctest_include_file "${ctest_file_base}_include-$<CONFIG>.cmake")
set(ctest_tests_file "${ctest_file_base}_tests-$<CONFIG>.cmake")
Once #12877 lands, maybe this can be revisited.
Co-authored-by: Ryan Thornton <ThorntonRyan@JohnDeere.com>
Co-authored-by: Kevin Puetz <PuetzKevinA@JohnDeere.com>
Now, the unit tests are ran twice -- once with POST_BUILD (i.e. default mode)
and again with PRE_TEST (i.e. new discovery mode).
Both modes of setting gtest discovery mode are also tested:
1. Using the global override (i.e. CMAKE_GTEST_DISCOVER_TESTS_DISCOVERY_MODE)
2. Explicitly passing DISCOVERY_MODE in calls to gtest_discover_tests (in GoogleTestDiscoveryTimeout.cmake)
The goal is to show that the new PRE_TEST discovery mode does not break existing behavior
(i.e. should not break POST_BUILD mode) and should also pass the same tests
in the same way.
A few non trivial implementation details worth noting:
1. Refactoring discovery_timeout_test into own project
Originally, I tried doing:
```
run_GoogleTest(POST_BUILD)
run_GoogleTest(PRE_TEST)
```
Without changing the internal structure of run_GoogleTest.
But since discovery_timeout_test is part of the same project as the other tests,
and CTest include files always get evaluated and that's where test discovery occurs,
this means every other test now notices the timeout problem when running in PRE_TEST mode.
As a result, keeping the existing test structure meant that each existing test
(and any new test) would need to have its own PRE_TEST / POST_BUILD variant for stderr and stdout
in order to handle the case where discovery_timeout_test timed out.
This exponential increase in test output files introduced unnecessary complexity
and made it more cumbersome to work on test cases.
Why should an unrelated test case care about discovery_timeout_test?
So, to fix that issue, the tests were broken apart into two main groups:
1. run_GoogleTest_discovery_timeout (the test dealing with discovery_timeout_test)
2. run_GoogleTest (everything else)
This isolates the PRE_TEST / POST_BUILD timeout variants to a single test case.
And the other test cases remain unchanged -- further driving home the point that
DISCOVERY_MODE shouldn't change existing behavior.
2. Different number of PRE_TEST / POST_BUILD file variants
On the PRE_TEST path, different build systems / compilers (i.e. MSBuild and ninja/gcc)
produces different build output when building discovery_timeout_test,
but we don't actually care what it is, just as long as it builds
successfully.
This the fundamental difference in behavior between POST_BUILD (which would have failed)
and PRE_TEST (which doesn't) and is the reason why we don't need
a GoogleTest-discovery-build-result.txt or GoogleTest-discovery-build-stdout.txt
3. Fix flaky discovery timeout test
The test expects to see:
> Output:
> timeout
> case.
But sometimes, the test would only produce:
> Output:
> timout
In certain environments, specifically when built with OpenWatcom 1.4,
and while the build server was under heavy load (i.e. running many tests in parallel),
std::endl behaves inconsistently and doesn't completely
flush std::cout when the program is terminated due to timeout.
This results in inconsistent test failures because the actual output
doesn't fully match what's expected.
At first we tried adding an additional:
std::cout << std::flush
That didn't work. But using C-style printf() and fflush() appears to do
the trick:
> This time I managed to get on the machine while it was still busy doing other nightly builds
> and could reproduce the problem reliably. With that I was finally able to find a fix.
> It turns out my earlier hypothesis that C++ stream flushing was not working on the old compiler was correct,
> but even .flush() is not enough.
> I changed it to use C-style printf() and fflush() and now the test passes on that build.
> -- Brad King <brad.king@kitware.com>
Co-authored-by: Ryan Thornton <ThorntonRyan@JohnDeere.com>
Co-authored-by: Kevin Puetz <PuetzKevinA@JohnDeere.com>
Since commit d1976cd1f2 (CTest: Fix timeout when grandchild keeps pipes
open, 2020-01-13, v3.17.0-rc1~169^2) we no longer hang, but the test
duration we report after the timeout is the amount of time the immediate
child ran before exiting. Fix the logic to instead report the actual
amount of time we spent monitoring the test before the timeout.
Fixes: #20509
ec7928ef26 use _s to construct static string_views at several places
94de927cab VS10Generator: avoid many string allocations
8ca2504a4d use string_views to avoid memory allocations
761f1adcae check for a valid URL scheme before starting to do any splitting
ef778d77e0 replace std::string::substr() with operations that do not allocate memory
77616f4681 pass cm::string_view to cmVisualStudioSlnParser::ParseTag()
ada6a3226f use cm::string_view for language extension lookups
48adc29721 replace "std::string::find(x) == 0" with cmHasPrefix()
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4501
CMake 3.16 and below allow multiple `export()` calls with the same output
file even without using `APPEND`. The implementation worked by accident
by leaking memory. Refactoring in commit 5444a8095d (cmGlobalGenerator:
modernize memrory managemenbt, 2019-12-29, v3.17.0-rc1~239^2) cleaned up
that memory leak and converted it to a use-after-free instead.
The problem is caused by using the `cmGlobalGenerator::BuildExportSets`
map to own `cmExportBuildFileGenerator` instances. It can own only
one instance per output FILE name at a time, so repeating use of the
same file now frees the old `cmExportBuildFileGenerator` instance
and leaves the pointer in the `cmMakefile::ExportBuildFileGenerators`
vector dangling. Move ownership of the instances into `cmMakefile`'s
vector since its entries are not replaced on a repeat output FILE.
In future work we should introduce a policy to error out on this case.
For now simply fix the use-after-free to restore CMake <= 3.16 behavior.
Fixes: #20469
46064c8193 FindRuby: Add support for versions up to 2.7
675eaf3bd0 FindRuby: Update MSVC runtime library selection
b970e25d98 FindRuby: Remove extra whitespace
ecdace4d61 FindRuby: Include FPHSA closer to where it is used
f52f496138 FindRuby: Provide Ruby_LIBRARIES result variable
b00d736a0b FindRuby: Add dedicated tests
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4481
In commit 3dab4682f6 (FindPython: reduces consumption of resources,
2020-02-10, v3.17.0-rc1~11^2) we accidentally broke the python
executable version validation when the "LOCATION" strategy is used
with the plain `FindPython` module. Fix the logic and add test
cases covering those combinations.
Fixes: #20465
9728839b9e ASM: Fix executable link lines with GNU 'as' tool as CMAKE_ASM_COMPILER
5932f0be4f ASM: Fix depfile flags for GNU 'as' tool
0d0aa98c84 ASM: Record vendor-specific output matched to identify assembler
ee3ec27465 CMakeDetermineCompilerId: Set locale to C for vendor output match
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4460
The GNU `as --help` shows `--MD <file>` as an option to generate depfiles
as needed by Ninja. There is no `-MT <target>` flag but fortunately the
generated files automatically account for the `-o <obj>` flag.
Issue: #20426
Teach include directory computation for Swift to implicitly propagate
the `Swift_MODULE_DIRECTORY` of all linked targets as include
directories. This is required to ensure that the swiftmodule of a
linked target is accessible to the compiler of the current target.
Fixes: #19272
The properties added by commit 4a62e3d97c (macOS: Add
OSX_COMPATIBILITY_VERSION and OSX_CURRENT_VERSION properties,
2020-01-24, v3.17.0-rc1~80^2~1) are general-purpose for all platforms
using Mach-O formats and not just on OS X. Rename them accordingly.
The properties are new to the CMake 3.17 release so we can rename
them without compatibility concerns.
Fixes: #20442
Discovery timeout test needs split out into two components:
- build
- test
Building the project should result in a failure due to the timeout
when executing gtest discovery as a post build step.
Likewise, if you ran CTest after this build failure,
we should *also* detect that the discovery_timeout_test has not been built
because no discovery_timeout_test[1]_tests.cmake has been created
due to the test discovery failure (caused by the timeout).
Use recommended case for variable names, i.e. matching name of the
module as passed to `find_package`.
For backwards compatibility, the upper case versions of both input and
output variables are used and defined when appropriate. Skip this for
the _FOUND variable because FPHSA already does it.
This follows the approach from commit a7b09e7f43 (FindProtobuf: Rename
variables to match case of module name, 2016-03-01, v3.6.0-rc1~273^2).
Issue: #20370
Extend the `file()` command with a new `CONFIGURE` subcommand that
behaves the same as `string(CONFIGURE)` except that it writes the
resulting output immediately to a file.
Fixes: #20388