| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introducing a new DISCOVERY_MODE mode option, which provides greater control
over when gtest_discover_tests perforsm test discovery.
It has two supported modes:
* POST_BUILD
* PRE_TEST
POST_BUILD is the default behavior, which adds a POST_BUILD command
to perform test discovery after the test has been built.
PRE_TEST is a new mode, which delays test discovery until test execution.
DISCOVERY_MODE can be controlled in two ways:
1. Setting the DISCOVERY_MODE when calling gtest_discover_tests
2. Setting the global CMAKE_GTEST_DISCOVER_TESTS_DISCOVERY_MODE
prior to calling gtest_discover_tests
By delaying test discovery until ctest runtime,
we can provide better cross compile support,
because we're more likely to be in an environment that can run the test executable.
This was achieved by moving the command for test discovery
into the generated ctest include file.
In PRE_TEST mode, the generated include file now has the form:
if(EXISTS "path/to/test.exe")
if("path/to/test.exe" IS_NEWER_THAN "path/to/ctest_file")
// command to discover tests
// and generate ctest_file
endif()
include("path/to/ctest_file")
endif()
elseif()
// test not built
endif()
Which generates the appropriate CTest files at runtime
and regenerates the CTest files when the executable is updated.
In the old approach, test discovery was always added as POST_BUILD step
and the executable was ran in order to scan for tests.
If the test executable failed to run for any reason,
this resulted in a link failure.
This failure could more commonly occur when cross compiling,
because your build environment might not have
the appropriate runtime environment dlls required to run the test executable.
I also ran into the issue when compiling a Qt application using Qt Creator.
Qt Creator manages its build and runtime environments separately
and only adds the Qt dlls to the environment during runtime -- not during build.
So when gtest_discover_tests ran my test executable,
it promptly crashed because the environment wasn't correct,
which resulted in a build failure.
Setting the DISCOVERY_MODE to PRE_TEST fixed my build failure
by delaying test discovery until runtime,
because this allowed the test exe to run in the proper environment.
A few non-trivial implementation details worth noting:
1. bracket_arguments
In the PRE_TEST side, parameters whose contents might contain special characters,
need to be handled with great care.
To aid in escaping these list arguments, backslashes, and other special characters,
and ensuring that they are preserved in the generated file,
bracket arguments (i.e. [== <...> ==]) are used.
For example:
gtest_discover_tests(
...
EXTRA_ARGS how now "\"brown\" cow"
)
Generates a file with the following call:
gtest_discover_tests_impl(
...
TEST_EXTRA_ARGS [==[how;now;"brown" cow]==]
)
This way the arguments are forwarded correctly.
2. multi-config generators
Multi-Config generators (e.g. MSBuild) now work more correctly in
PRE_TEST than POST_BUILD.
PRE_TEST is more correct because it will generate a unique CTest file for each configuration.
It generates a per config file responsible for test discovery:
foo[1]_include-Debug.cmake
foo[1]_include-MinSizeRel.cmake
foo[1]_include-Release.cmake
foo[1]_include-RelWithDebInfo.cmake
A per config file for containing the google tests:
foo[1]_tests-Debug.cmake
And an outer ctest file:
foo[1]_include-Debug.cmake
That is generically written to include the correct configuration file
by looking at the value of ${CTEST_CONFIGURATION_TYPE} when CTest runs.
POST_BUILD, in contrast, preserves the existing functionality.
Tests are disocvered based on the last configuration that was chosen
and only a single file is produced:
foo[1]_include.cmake
foo[1]_tests.cmake
But it runs with whatever executable requested by ctest --config,
which means it's possible to run the wrong tests
if some tests were enabled in one configuration but not another.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move test discovery logic into new gtest_discover_tests_impl method
and make GoogleTestAddTests aware of whether it is being launched in
CMake's script mode.
When launched in script mode, gtest_discover_tests_impl is called
passing arguments obtained from the definitions passed into the call to cmake.
(i.e. cmake -P GoogleTestAddTests -D <arg1> -D <arg2> ...)
This preserves the existing behavior assumed by GoogleTest.cmake.
Unit tests are unchanged and still pass.
Looking ahead, it also allows GoogleTestAddTests to be included in generated files
and call gtest_discover_tests_impl to perform test discovery at test runtime
with the new PRE_TEST discovery mode introduced later in this branch.
My original approach attempted to call execute_process(cmake -P ...) in
the generated file, the same way POST_BUILD is doing, but I ran into
difficulties serializing the command arguments correctly.
By exposing a way to call gtest_discover_tests_impl directly from our generated file,
we remove a layer of shell quoting / parsing that our arguments have to survive,
which simplifies the act of producing a generated file that behaves the
same as its POST_BUILD counterpart.
|
|\
| |
| |
| |
| |
| |
| | |
bd89133543 cmState::GetCacheEntryValue: return cmProp
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4493
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
b915fec56e cmTarget: minor code improvements
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4483
|
| |/ |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
36baf1f13c CheckLanguage: hide commonly used variable names
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4497
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The check_language sets internal variables with a common name in the
caller's scope: `result`, `output` and `content`.
They are now prefixed with `_cl_`,
inspired by the CheckLibraryExists module.
|
|\ \ \ |
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
1994f950ff cmake: List valid values for --trace-format on the command line
e39766d84a Help: Fix documentation of --trace-format parameter
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4500
|
|\ \ \ \ \
| | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
1994f950ff cmake: List valid values for --trace-format on the command line
e39766d84a Help: Fix documentation of --trace-format parameter
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4500
|
| | | | | |
|
| |/ / / |
|
| |/ /
|/| | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| | | |
| | | |
| | | |
| | | | |
Fixes: #20370
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Use the `MSVC_TOOLSET_VERSION` variable computed by CMake to get the
matching Ruby library name component.
Inspired-by: Julien Marrec <julien.marrec@gmail.com>
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
The `cmake-developer(7)` manual documents that a plural non-cached
name should be used for results.
|
| | | |
| | | |
| | | |
| | | | |
Issue: #20370
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
1c99f5df28 FindPkgConfig: Add test for specified pkg-config tool missing
b59f36aad8 FindPkgConfig: Unset results when pkg-config is broken
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4451
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Inspired-by: FUJI Goro <goro@fastly.com>
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
2ec6fbcb9b bootstrap: Tolerate trailing content in CMakeVersion.cmake components
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4491
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
On CYGWIN, tolerate DOS linefeeds in `Source/CMakeVersion.cmake`.
|
|\ \ \ \ \ \
| | |_|_|/ /
| |/| | | | |
|
| |\ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
cc7f116cb4 FindPython: fix regression on version validation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4492
|
|\ \ \ \ \ \ \
| | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
cc7f116cb4 FindPython: fix regression on version validation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4492
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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
|
| |_|_|_|_|/
|/| | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
c7e1198a23 file: Add ARCHIVE_{CREATE|EXTRACT} subcommands
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4475
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fixes: #20443
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
fad0ee5404 cmTargetPropertyComputer::GetProperty: return cmProp
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4482
|
| | |_|_|/ / /
| |/| | | | | |
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
60f57d0dcc cmPropertyMap: Introduce cmProp as return type for GetProperty() functions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4471
|
| | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Currently properties are usually stored internally as `std::string`.
However, family of GetProperty() functions return them as `const char *` using `c_str()`.
The proposed `cmProp`, typedef'ed as `const std::string *` will expose properties
more naturally.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
897af4c266 cmMakefileProfilingData: Fix ambiguous conversion to Json::Value
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4479
|
| | | | | | | | |
|
|\ \ \ \ \ \ \ \
| | |_|_|_|/ / /
| |/| | | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
1502f281dd FindThreads: Improve documentation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4480
|
|\ \ \ \ \ \ \ \ \
| | |/ / / / / / /
| |/| | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
1502f281dd FindThreads: Improve documentation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4480
|
| | |_|_|_|/ / /
| |/| | | | | |
| | | | | | | |
| | | | | | | | |
Issue: #19823
|
| |_|_|_|/ / /
|/| | | | | | |
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
73d52a862b cmPropertyDefinition: Construct directly in defined state
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4470
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Move `cmPropertyDefinitionMap::DefineProperty` functionality
directly into the constructor to avoid an intermediate state.
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
32bc6aa9b6 GoogleTest: Add release note for XML_OUTPUT_DIR
0001339a6f GoogleTest: Add test case for XML_OUTPUT_DIR
e9ab39eb1d GoogleTest: Add XML_OUTPUT_DIR parameter
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4433
|
| | | | | | | | | |
|
| | | | | | | | | |
|