2010-09-24 17:01:13 +08:00
|
|
|
########################################################################
|
|
|
|
|
# Experimental CMake build script for Google Test.
|
|
|
|
|
#
|
|
|
|
|
# Consider this a prototype. It will change drastically. For now,
|
|
|
|
|
# this is only for people on the cutting edge.
|
|
|
|
|
#
|
|
|
|
|
# To run the tests for Google Test itself on Linux, use 'make test' or
|
|
|
|
|
# ctest. You can select which tests to run using 'ctest -R regex'.
|
|
|
|
|
# For more options, run 'ctest --help'.
|
|
|
|
|
########################################################################
|
|
|
|
|
#
|
|
|
|
|
# Project-wide settings
|
|
|
|
|
|
|
|
|
|
# Where gtest's .h files can be found.
|
|
|
|
|
include_directories(
|
|
|
|
|
googletest/include
|
2013-11-15 18:20:45 +08:00
|
|
|
googletest
|
Add the 'googlemock' component of Google Test to LLVM's unittest libraries.
I have two immediate motivations for adding this:
1) It makes writing expectations in tests *dramatically* easier. A
quick example that is a taste of what is possible:
std::vector<int> v = ...;
EXPECT_THAT(v, UnorderedElementsAre(1, 2, 3));
This checks that v contains '1', '2', and '3' in some order. There
are a wealth of other helpful matchers like this. They tend to be
highly generic and STL-friendly so they will in almost all cases work
out of the box even on custom LLVM data structures.
I actually find the matcher syntax substantially easier to read even
for simple assertions:
EXPECT_THAT(a, Eq(b));
EXPECT_THAT(b, Ne(c));
Both of these make it clear what is being *tested* and what is being
*expected*. With `EXPECT_EQ` this is implicit (the LHS is expected,
the RHS is tested) and often confusing. With `EXPECT_NE` it is just
not clear. Even the failure error messages are superior with the
matcher based expectations.
2) When testing any kind of generic code, you are continually defining
dummy types with interfaces and then trying to check that the
interfaces are manipulated in a particular way. This is actually what
mocks are *good* for -- testing *interface interactions*. With
generic code, there is often no "fake" or other object that can be
used.
For a concrete example of where this is currently causing significant
pain, look at the pass manager unittests which are riddled with
counters incremented when methods are called. All of these could be
replaced with mocks. The result would be more effective at testing
the code by having tighter constraints. It would be substantially
more readable and maintainable when updating the code. And the error
messages on failure would have substantially more information as
mocks automatically record stack traces and other information *when
the API is misused* instead of trying to diagnose it after the fact.
I expect that #1 will be the overwhelming majority of the uses of gmock,
but I think that is sufficient to justify having it. I would actually
like to update the coding standards to encourage the use of matchers
rather than any other form of `EXPECT_...` macros as they are IMO
a strict superset in terms of functionality and readability.
I think that #2 is relatively rarely useful, but there *are* cases where
it is useful. Historically, I think misuse of actual mocking as
described in #2 has led to resistance towards this framework. I am
actually sympathetic to this -- mocking can easily be overused. However
I think this is not a significant concern in LLVM. First and foremost,
LLVM has very careful and rare exposure of abstract interfaces or
dependency injection, which are the most prone to abuse with mocks. So
there are few opportunities to abuse them. Second, a large fraction of
LLVM's unittests are testing *generic code* where mocks actually make
tremendous sense. And gmock is well suited to building interfaces that
exercise generic libraries. Finally, I still think we should be willing
to have testing utilities in tree even if they should be used rarely. We
can use code review to help guide the usage here.
For a longer and more complete discussion of this, see the llvm-dev
thread here:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/108672.html
The general consensus seems that this is a reasonable direction to start
down, but that doesn't mean we should race ahead and use this
everywhere. I have one test that is blocked on this to land and that was
specifically used as an example. Before widespread adoption, I'm going
to work up some (brief) guidelines as some of these facilities should be
used sparingly and carefully.
Differential Revision: https://reviews.llvm.org/D28156
llvm-svn: 291606
2017-01-11 06:32:26 +08:00
|
|
|
googlemock/include
|
|
|
|
|
googlemock
|
2010-09-24 17:01:13 +08:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
if(WIN32)
|
|
|
|
|
add_definitions(-DGTEST_OS_WINDOWS=1)
|
|
|
|
|
endif()
|
|
|
|
|
|
2019-06-07 23:45:25 +08:00
|
|
|
# Google Test requires headers which need _ALL_SOURCE to build on AIX
|
|
|
|
|
if (UNIX AND ${CMAKE_SYSTEM_NAME} MATCHES "AIX")
|
|
|
|
|
remove_definitions("-D_XOPEN_SOURCE=700")
|
|
|
|
|
add_definitions("-D_ALL_SOURCE")
|
|
|
|
|
endif()
|
|
|
|
|
|
2017-01-07 07:16:00 +08:00
|
|
|
if(SUPPORTS_VARIADIC_MACROS_FLAG)
|
2010-10-08 02:12:54 +08:00
|
|
|
add_definitions("-Wno-variadic-macros")
|
|
|
|
|
endif()
|
2017-01-07 07:16:00 +08:00
|
|
|
if(SUPPORTS_GNU_ZERO_VARIADIC_MACRO_ARGUMENTS_FLAG)
|
2017-01-05 07:06:03 +08:00
|
|
|
add_definitions("-Wno-gnu-zero-variadic-macro-arguments")
|
|
|
|
|
endif()
|
|
|
|
|
if(CXX_SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG)
|
|
|
|
|
add_definitions("-Wno-covered-switch-default")
|
|
|
|
|
endif()
|
2010-10-08 02:12:54 +08:00
|
|
|
|
2010-10-17 10:26:16 +08:00
|
|
|
set(LLVM_REQUIRES_RTTI 1)
|
|
|
|
|
add_definitions( -DGTEST_HAS_RTTI=0 )
|
|
|
|
|
|
2017-02-10 09:59:20 +08:00
|
|
|
find_library(LLVM_PTHREAD_LIBRARY_PATH pthread)
|
|
|
|
|
if (LLVM_PTHREAD_LIBRARY_PATH)
|
2015-01-21 05:23:15 +08:00
|
|
|
list(APPEND LIBS pthread)
|
|
|
|
|
endif()
|
|
|
|
|
|
2010-09-26 04:25:25 +08:00
|
|
|
add_llvm_library(gtest
|
2013-11-15 18:20:45 +08:00
|
|
|
googletest/src/gtest-all.cc
|
Add the 'googlemock' component of Google Test to LLVM's unittest libraries.
I have two immediate motivations for adding this:
1) It makes writing expectations in tests *dramatically* easier. A
quick example that is a taste of what is possible:
std::vector<int> v = ...;
EXPECT_THAT(v, UnorderedElementsAre(1, 2, 3));
This checks that v contains '1', '2', and '3' in some order. There
are a wealth of other helpful matchers like this. They tend to be
highly generic and STL-friendly so they will in almost all cases work
out of the box even on custom LLVM data structures.
I actually find the matcher syntax substantially easier to read even
for simple assertions:
EXPECT_THAT(a, Eq(b));
EXPECT_THAT(b, Ne(c));
Both of these make it clear what is being *tested* and what is being
*expected*. With `EXPECT_EQ` this is implicit (the LHS is expected,
the RHS is tested) and often confusing. With `EXPECT_NE` it is just
not clear. Even the failure error messages are superior with the
matcher based expectations.
2) When testing any kind of generic code, you are continually defining
dummy types with interfaces and then trying to check that the
interfaces are manipulated in a particular way. This is actually what
mocks are *good* for -- testing *interface interactions*. With
generic code, there is often no "fake" or other object that can be
used.
For a concrete example of where this is currently causing significant
pain, look at the pass manager unittests which are riddled with
counters incremented when methods are called. All of these could be
replaced with mocks. The result would be more effective at testing
the code by having tighter constraints. It would be substantially
more readable and maintainable when updating the code. And the error
messages on failure would have substantially more information as
mocks automatically record stack traces and other information *when
the API is misused* instead of trying to diagnose it after the fact.
I expect that #1 will be the overwhelming majority of the uses of gmock,
but I think that is sufficient to justify having it. I would actually
like to update the coding standards to encourage the use of matchers
rather than any other form of `EXPECT_...` macros as they are IMO
a strict superset in terms of functionality and readability.
I think that #2 is relatively rarely useful, but there *are* cases where
it is useful. Historically, I think misuse of actual mocking as
described in #2 has led to resistance towards this framework. I am
actually sympathetic to this -- mocking can easily be overused. However
I think this is not a significant concern in LLVM. First and foremost,
LLVM has very careful and rare exposure of abstract interfaces or
dependency injection, which are the most prone to abuse with mocks. So
there are few opportunities to abuse them. Second, a large fraction of
LLVM's unittests are testing *generic code* where mocks actually make
tremendous sense. And gmock is well suited to building interfaces that
exercise generic libraries. Finally, I still think we should be willing
to have testing utilities in tree even if they should be used rarely. We
can use code review to help guide the usage here.
For a longer and more complete discussion of this, see the llvm-dev
thread here:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/108672.html
The general consensus seems that this is a reasonable direction to start
down, but that doesn't mean we should race ahead and use this
everywhere. I have one test that is blocked on this to land and that was
specifically used as an example. Before widespread adoption, I'm going
to work up some (brief) guidelines as some of these facilities should be
used sparingly and carefully.
Differential Revision: https://reviews.llvm.org/D28156
llvm-svn: 291606
2017-01-11 06:32:26 +08:00
|
|
|
googlemock/src/gmock-all.cc
|
2010-09-24 17:01:13 +08:00
|
|
|
|
2014-02-26 14:41:29 +08:00
|
|
|
LINK_LIBS
|
2015-01-21 05:23:15 +08:00
|
|
|
${LIBS}
|
2016-02-12 09:42:43 +08:00
|
|
|
|
|
|
|
|
LINK_COMPONENTS
|
|
|
|
|
Support # Depends on llvm::raw_ostream
|
2016-09-10 03:45:34 +08:00
|
|
|
|
|
|
|
|
# This is a library meant only for the build tree.
|
|
|
|
|
BUILDTREE_ONLY
|
2015-01-21 05:23:15 +08:00
|
|
|
)
|
2014-02-10 19:27:41 +08:00
|
|
|
|
2020-07-27 23:37:01 +08:00
|
|
|
# The googletest and googlemock sources don't presently use the 'override'
|
|
|
|
|
# keyword, which leads to lots of warnings from -Wsuggest-override. Disable
|
|
|
|
|
# that warning here for any targets that link to gtest.
|
|
|
|
|
if(CXX_SUPPORTS_SUGGEST_OVERRIDE_FLAG)
|
|
|
|
|
add_definitions("-Wno-suggest-override")
|
|
|
|
|
set_target_properties(gtest PROPERTIES INTERFACE_COMPILE_OPTIONS "-Wno-suggest-override")
|
|
|
|
|
endif()
|
|
|
|
|
|
2020-07-28 21:26:23 +08:00
|
|
|
# Gtest 1.8.0 uses tr1/tuple which is deprecated on MSVC, so we force it off.
|
|
|
|
|
target_compile_definitions(gtest PUBLIC GTEST_HAS_TR1_TUPLE=0)
|
|
|
|
|
|
|
|
|
|
if (NOT LLVM_ENABLE_THREADS)
|
|
|
|
|
target_compile_definitions(gtest PUBLIC GTEST_HAS_PTHREAD=0)
|
|
|
|
|
endif ()
|
|
|
|
|
|
2014-01-10 19:02:26 +08:00
|
|
|
add_subdirectory(UnitTestMain)
|
CMake: Make most target symbols hidden by default
Summary:
For builds with LLVM_BUILD_LLVM_DYLIB=ON and BUILD_SHARED_LIBS=OFF
this change makes all symbols in the target specific libraries hidden
by default.
A new macro called LLVM_EXTERNAL_VISIBILITY has been added to mark symbols in these
libraries public, which is mainly needed for the definitions of the
LLVMInitialize* functions.
This patch reduces the number of public symbols in libLLVM.so by about
25%. This should improve load times for the dynamic library and also
make abi checker tools, like abidiff require less memory when analyzing
libLLVM.so
One side-effect of this change is that for builds with
LLVM_BUILD_LLVM_DYLIB=ON and LLVM_LINK_LLVM_DYLIB=ON some unittests that
access symbols that are no longer public will need to be statically linked.
Before and after public symbol counts (using gcc 8.2.1, ld.bfd 2.31.1):
nm before/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l
36221
nm after/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l
26278
Reviewers: chandlerc, beanz, mgorny, rnk, hans
Reviewed By: rnk, hans
Subscribers: merge_guards_bot, luismarques, smeenai, ldionne, lenary, s.egerton, pzheng, sameer.abuasal, MaskRay, wuzish, echristo, Jim, hiraditya, michaelplatings, chapuni, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, mgrang, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, kristina, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D54439
2020-01-15 11:15:07 +08:00
|
|
|
|
|
|
|
|
# When LLVM_LINK_LLVM_DYLIB is enabled, libLLVM.so is added to the interface
|
|
|
|
|
# link libraries for gtest and gtest_main. This means that any target, like
|
|
|
|
|
# unittests for example, that links against gtest will be forced to link
|
|
|
|
|
# against libLLVM.so. In some cases we may want to statically unittests if they
|
|
|
|
|
# need access to symbols that are marked private in libLLVM.so. The only
|
|
|
|
|
# way we can make this work is to remove libLLVM.so from the list of interface
|
|
|
|
|
# link libraries for gtest and then make gtest users responsible for explicitly
|
|
|
|
|
# adding libLLVM.so to their targets link libraries if they need it.
|
|
|
|
|
|
|
|
|
|
function (gtest_remove_dylib_from_link_interface target)
|
|
|
|
|
get_target_property(interface_libs ${target} INTERFACE_LINK_LIBRARIES)
|
|
|
|
|
if (interface_libs)
|
|
|
|
|
list(REMOVE_ITEM interface_libs LLVM)
|
|
|
|
|
set_target_properties(${target} PROPERTIES INTERFACE_LINK_LIBRARIES "${interface_libs}")
|
|
|
|
|
endif()
|
|
|
|
|
endfunction()
|
|
|
|
|
|
|
|
|
|
gtest_remove_dylib_from_link_interface(gtest)
|
|
|
|
|
gtest_remove_dylib_from_link_interface(gtest_main)
|