18

I am trying to integrate GTest with CMake as seamlessly as possible. But the default build type for my test projects are /MDd and GTest defaults to /MTd. I am manually changing GTest project properties to emit debug DLL.

But every time I make changes to my CMakeLists.txt, GTest defaults back to /MTd. How do I stop this?

Hindol
  • 2,924
  • 2
  • 28
  • 41

4 Answers4

37

You can define gtest_force_shared_crt to ON before including gtest to achieve this. You can either do this via the command line:

cmake . -Dgtest_force_shared_crt=ON

or in your CMakeLists.txt:

set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
Florian Wolters
  • 3,820
  • 5
  • 35
  • 55
Fraser
  • 74,704
  • 20
  • 238
  • 215
  • 2
    You should add Ted Middleton's correction from below. Adding the set() line, as you suggest it, has no influence on the gtest build. – Ela782 Aug 16 '14 at 22:53
14

I think a better option is @Fraser's answer - in that case, cmake + gtest 'just work'.

It's worth mentioning that in order to override the internal gtest option setting, you need to put the variable in the cmake cache:

set( gtest_force_shared_crt ON CACHE BOOL "Always use msvcrt.dll" )
Ted Middleton
  • 6,859
  • 10
  • 51
  • 71
7

If Ted Middleton's answer doesn't work, try to use FORCE:

set( gtest_force_shared_crt ON CACHE BOOL "Always use msvcrt.dll" FORCE)

It worked for me

Pacific Mariner
  • 71
  • 1
  • 2
1

We solved the problem by bypassing GTest's own build system and compiling GTest as a CMake object library from its unity build source file gtest-all.cc:

# compile Google Test as an object library
add_library(gtest OBJECT "${CMAKE_CURRENT_SOURCE_DIR}/gtest-1.6.0/src/gtest-all.cc")
set_property(TARGET gtest PROPERTY INCLUDE_DIRECTORIES
    "${CMAKE_CURRENT_SOURCE_DIR}/gtest-1.6.0"
    "${CMAKE_CURRENT_SOURCE_DIR}/gtest-1.6.0/include")

That way GTest will always be compiled with the same options that we use for the project. A test executable that uses GTest can then be built in the following way:

add_executable(test_executable ${TESTS_SRC} $<TARGET_OBJECTS:gtest>)
add_test(NAME test COMMAND test_executable)
sakra
  • 62,199
  • 16
  • 168
  • 151
  • On linux, GTest depends on the `pthreads` library. How do I associate such a dependency on the `gtest` object? – Hindol Sep 24 '12 at 05:45
  • Created a [separate question](http://stackoverflow.com/questions/12560054/how-to-set-library-dependencies-on-cmake-library-objects) for this. – Hindol Sep 24 '12 at 06:49
  • This way, you recompile the entire source of gtest for every separate test executable - not very efficient. You also lose all the checks and settings that are contained in gtest's own CMakeLists.txt, one repercussion being the missing dependency on pthread on Linux. – Fraser Sep 26 '12 at 19:49
  • @Fraser The gtest source is *not* recompiled for every test executable. Object libraries were precisely added as a feature to reuse a compiled object file for many targets. – sakra Sep 26 '12 at 20:11
  • 1
    @sakra - Ah yes, you're right! Sorry. I still prefer to use GTest's own build file. They added the `gtest_force_shared_crt` option for precisely this case. Also, we use fairly high warning levels and treat warnings as errors, so it's convenient to have a different set of compiler options for third party libs. – Fraser Sep 26 '12 at 20:28