[Bug]: Passing -DGTEST_HAS_RTTI=0 using cmake has no effect

[eyalgolan1337]

Describe the issue

When passing -DGTEST_HAS_RTTI=0 to cmake the value of GTEST_HAS_RTTI still ends being 1, which causes gtest to use typeid. This is obviously a problem when trying to use gtest with code that was compiled with -fno-rtti.

As a side-note, I ran into this problem when using gtest though vcpkg, so in order to define this preprocessor macro i had to add a patch to gtest's CMakeLists.txt and add add_definitions(-DGTEST_HAS_RTTI=0) because it does not support passing the options defined in gtest-port.h. Consider adding support for these options in the cmakelists file in the future so a patch is not needed and instead passing GTEST_HAS_RTTI=OFF to vcpkg_cmake_configure will be enough

Steps to reproduce the problem

try and link gtest compiled with -DGTEST_HAS_RTTI=0 into a binary compiled with -fno-rtti. The problem occurs when trying to use TYPED_TEST_SUITE()

What version of GoogleTest are you using?

1.14.0 through vcpkg

What operating system and version are you using?

ubuntu22.04

What compiler and version are you using?

gcc 13.2

What build system are you using?

cmake 3.28

Additional context

No response

[phetdam]

Doing a code search in the Google Test GitHub for GTEST_HAS_RTTI seems to show that this macro is only used in end-user headers or in the project's own test programs, and it does say in gtest-port.h that macros like GTEST_HAS_RTTI are supposed to be tweaked by end-users. Therefore, it seems that whether Google Test is compiled with or without -DGTEST_HAS_RTTI=0 won't make a difference for end-user code as its value doesn't seem to affect how the library code itself is compiled.

It might thus be better to not have this be a build-time option as again, GTEST_HAS_RTTI only affects the Google Test headers, so a single Google Test package can be used to serve both users and non-users of RTTI. In this sense, I don't think this is a bug per se, but it could be definitely annoying for someone compiling their project without RTTI.

In the no-RTTI case, either globally defining or -DGTEST_HAS_RTTI=0 could be done in the way you showed:

# globally define for all targets in this and subsequent scopes
add_compile_definitions(GTEST_HAS_RTTI=0)

Or, this could be done on a per-target basis:

# for some specific target called "abc". we allow propagation of this requirement to downstream targets
target_compile_definitions(abc PUBLIC GTEST_HAS_RTTI=0)

I would also recommend, if it suits your use case, to define your own imported target that you can link against instead of GTest::gtest or GTest::gtest_main; I've done this with PyTorch for example to silence some ignorable MSVC compiler warnings and to also ensure special compile definitions get propagated to other targets. E.g. this could be of interest:

# good to have some kind of project namespace
add_library(myproj::gtest INTERFACE IMPORTED)
# transitively depend on Google Test library and add compile definitions
target_link_libraries(myproj::gtest INTERFACE GTest::gtest)
target_compile_definitions(myproj::gtest INTERFACE GTEST_HAS_RTTI=0 MYPROJ_ACTIVATE_TESTING_MACRO)

Something similar could be done for GTest::gtest_main, and then instead of using these targets with target_link_libraries, the custom interface targets that have all the right compile definitions can be used instead:

# project test runner getting built
add_library(mytest test1.cc test22.cc)
target_link_libraries(mytest PRIVATE myproj::gtest)