Google Test returns parameter values for parametrized tests in two ways:
* As part of the test name - if a name_generator has been provided in
the test this will be the generated string, otherwise gtest will just
number all tests
* In a separate field of the json (or the text output) - this seems to
be a byte representation of the input data if the input data cannot be
converted to a string.
If the cmake parameter `NO_PRETTY_VALUES` to `gtest_discover_tests` has
not been set, the auto-generated test index - i.e. if no `name_generator
has been specified - is supposed to be replaced by the value parameter
from category 2 above. However, since commit 1cdceae8e3 (GoogleTest:
Parse discovered test list from JSON output if supported, 2025-05-02,
v4.2.0-rc1~533^2~2), the logic has been broken, in that the test suffix
is always replaced even though a name_generator has been configured.
Fix this by checking if the last part of the test name is an integer and
only then replace it.
Fixes: #27846
18d5daa7f3 file(DOWNLOAD/UPLOAD): Restore support for curl built without a TLS backend
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12104
18d5daa7f3 file(DOWNLOAD/UPLOAD): Restore support for curl built without a TLS backend
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12104
18d5daa7f3 file(DOWNLOAD/UPLOAD): Restore support for curl built without a TLS backend
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12104
18d5daa7f3 file(DOWNLOAD/UPLOAD): Restore support for curl built without a TLS backend
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12104
Since commit 38390245a2 (ctest: Require minimum TLS 1.2 by default,
2024-09-23, v3.31.0-rc1~47^2), our TLS-1.2 default fails with a curl
built without any TLS backend, causing even `file://` and `http://`
URLs to fail. Teach CMake to recognize both ways libcurl may report
that it was built without TLS support.
Fixes: #27849
Prior to CMake 4.2.0, projects using the EMSDK's toolchain file while
also enabling `TARGET_SUPPORTS_SHARED_LIBS` would link shared libraries
using our default `-shared` flag plus whatever `-sSIDE_MODULE` flag
the project added, if any. CMake 4.2.0 introduced builtin Emscripten
support, but since commit d361bf365e (Emscripten: Drop hard-coded
-sMAIN_MODULE and -sSIDE_MODULE flags, 2025-09-18, v4.2.0-rc1~146^2)
we still leave it to projects to add Emscripten-specific flags needed
to link shared libraries.
Restore the pre-4.2 behavior of adding the `-shared` flag. In
particular, this is needed for upcoming Emscripten support for real
shared libraries.
Issue: #27240
Update the list of known versions.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_91_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.91.0 source tree.
Dependencies differ from 1.90:
* Boost.Iostreams no longer depends on Boost.Regex
* Boost.Log no longer depends on Boost.Regex
Fixes: #27803
As of GCC 16, `gcc` implies `gcc_s_asneeded` but `g++` implies `gcc_s`.
When linking mixed C and C++ binaries, avoid listing one if the other is
already implied by the linker language.
Fixes: #27796
