When using INSTANTIATE_TEST_CASE_P with a lambda function which uses
'info' as parameter name, GCC complains that this would shadow
parameter 'info' used in the macro's VA_ARGS call.
If the user's cmakelists.txt first look for threads using
find_package(Threads), then set(gtest_disable_pthreads ON),
and then include googletest. GoogleTest will not look for
threads. But since they have already been found before in
user's cmakelists, it will use them regardless.
This helped me fix build issue in darktable-org/rawspeed
on windows/MSYS2, even though there are threads, and they
are usable, googletest build was failing with issues
about AutoHandle. I was first looking for threads, and only
then including googletest, so no matter the value of
gtest_disable_pthreads, it failed.
The other obvious solution is for user to first include
googletest, and only then look for threads by himself.
On single-configuration build systems as Makefile Generators, there is
no subdirectory for the configuration in the build tree - therefore ask
cmake for the subdir by using CMAKE_CFG_INTDIR, which is just '.' on
single-configuration build systems (Linux et al.).
This change speeds up the runtime of a value-parameterized test I have
which has lots of values with large strings full of unprintable
characters by 2x. I profiled it and traced most of the slowness during
googletest startup down to the way String::FormatHexInt was creating and
destroyed a stringstream for each character in the string for each
value.
VS2010 solution only to simplify old users (who used these solutions) upgrading to new gtest/gmock, new users should use CMake generated solutions. VS2010 solution can be opened in any new VS.
This policy setting will silence a warning when using with a visibility settings on targets. Due to the forced `cmake_minimum_version`, policy settings in CMakeLists calling this one (including the main CMakeLists) are lost, forcing the change to be made here.