Update CMake quickstart with find_package + add CMake source build guide #4682
Conversation
…ntent + update gtest_force_shared_crt comments
modified: docs/_data/navigation.yml
Add source-build-cmake.html to the guides section
new file: docs/source-build-cmake.md
Add CMake build instructions for *nix and Windows
|
If this is accepted maybe it can also address #3843 as it provides an "official" workaround via |
|
|
||
| # Since CMake 3.20 CONFIG can be omitted as the FindGTest find module will | ||
| # prefer the upstream (provided by Google Test) GTestConfig.cmake if available | ||
| find_package(GTest 1.15.0 REQUIRED CONFIG) |
There was a problem hiding this comment.
I think there is no need to differentiate; target_link_libraries should be directly followed by find_package.
There was a problem hiding this comment.
The target_link_libraries call is in the "Create and run a binary" section; here I just mirror the FetchContent section.
#3843 issue I have encountered and resolved myself, and I believe this is the approach most people would choose, source code building, then using |
|
find_package(benchmark REQUIRED)
target_link_libraries(MyTarget benchmark::benchmark) |
Yes, I just looked at their However, on Windows there needs to be extra attention on the C runtime being linked, which is why we want to distinguish the debug library in |
|
Positive |
This PR updates the GoogleTest documentation as follows:
find_packageWork was inspired by the conversation in #4681 and by previous experience building older (v1.10.0) versions of GoogleTest from source in Windows environments with both
gtest.libandgtestd.libinstalled side-by-side linked against the shared C runtime. This is common in Windows development environments as there is more than one C runtime library and loading multiple (possibly ABI-incompatible) instances of the C runtime is generally discouraged.