RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-22 02:33:06 +01:00
Code Issues Projects Releases Wiki Activity
ac2765e624
llvm-mirror/utils/unittest/CMakeLists.txt

94 lines
3.1 KiB
CMake
Raw Normal View History

CMake: Build unittests. llvm-svn: 114725
2010-09-24 11:01:13 +02: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
if(WIN32)
add_definitions(-DGTEST_OS_WINDOWS=1)
endif()
Build with _XOPEN_SOURCE defined on AIX Summary: It is useful to build with _XOPEN_SOURCE defined on AIX, enabling X/Open and POSIX compatibility mode, to work around stray macros and other bugs in the headers provided by the system and build compiler. This patch adds the config to cmake to build with _XOPEN_SOURCE defined on AIX with a few exceptions. Google Test internals require access to platform specific thread info constructs on AIX so in that case we build with _ALL_SOURCE defined instead. Libclang also uses header which needs _ALL_SOURCE on AIX so we leave that as is as well. We also add building on AIX with the large file API and doing CMake header checks with X/OPEN definitions so the results are consistent with the environment that will be present in the build. Reviewers: hubert.reinterpretcast, xingxue, andusy Reviewed By: hubert.reinterpretcast Subscribers: mgorny, jsji, cfe-commits, llvm-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D62533 llvm-svn: 362808
2019-06-07 17:45:25 +02: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()
[gtest] Detect warning flags using the positive spelling. Some GCC versions will accept any warning flag name after a '-Wno-', which would cause us to try to disable warnings with names GCC didn't understand. This will silently succeed unless there is some other output from GCC in which case we get weird cc1plus warnings about the warning name being bogus. There is still the issue that gtest sets warning flags for building gtest-all.cc using weird 'add_definitions' and the fact that there is a GCC version which warns on the variadic macro usage in gtest under -pedantic, but has no flag analogous to Clang's -Wgnu-zero-variadic-macro-argumnets to suppress this warning. I haven't been able to come up with any good solution here. The closest is to turn off -pedantic for those versions of GCC, but that seems really nasty. For now, those versinos of GCC aren't warning clean. If anyone is broken by this, I'll work on CMake logic to detect and disable -pedantic in these cases. llvm-svn: 291299
2017-01-07 00:16:00 +01:00
if(SUPPORTS_VARIADIC_MACROS_FLAG)
CMake: Fix warning in gtest. llvm-svn: 115935
2010-10-07 20:12:54 +02:00
add_definitions("-Wno-variadic-macros")
endif()
[gtest] Detect warning flags using the positive spelling. Some GCC versions will accept any warning flag name after a '-Wno-', which would cause us to try to disable warnings with names GCC didn't understand. This will silently succeed unless there is some other output from GCC in which case we get weird cc1plus warnings about the warning name being bogus. There is still the issue that gtest sets warning flags for building gtest-all.cc using weird 'add_definitions' and the fact that there is a GCC version which warns on the variadic macro usage in gtest under -pedantic, but has no flag analogous to Clang's -Wgnu-zero-variadic-macro-argumnets to suppress this warning. I haven't been able to come up with any good solution here. The closest is to turn off -pedantic for those versions of GCC, but that seems really nasty. For now, those versinos of GCC aren't warning clean. If anyone is broken by this, I'll work on CMake logic to detect and disable -pedantic in these cases. llvm-svn: 291299
2017-01-07 00:16:00 +01:00
if(SUPPORTS_GNU_ZERO_VARIADIC_MACRO_ARGUMENTS_FLAG)
[gtest] Upgrade googletest to version 1.8.0, minimizing local changes. This required re-working the streaming support and lit's support for '--gtest_list_tests' but otherwise seems to be a clean upgrade. Differential Revision: https://reviews.llvm.org/D28154 llvm-svn: 291029
2017-01-05 00:06:03 +01:00
add_definitions("-Wno-gnu-zero-variadic-macro-arguments")
endif()
if(CXX_SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG)
add_definitions("-Wno-covered-switch-default")
endif()
CMake: Fix warning in gtest. llvm-svn: 115935
2010-10-07 20:12:54 +02:00
Build with RTTI and exceptions disabled. Only in GCC for now. llvm-svn: 116682
2010-10-17 04:26:16 +02:00
set(LLVM_REQUIRES_RTTI 1)
add_definitions( -DGTEST_HAS_RTTI=0 )
[CMake] Fix pthread handling for out-of-tree builds LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects to correctly link the threading library when needed. Unfortunately `PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed and therefore can't be used when configuring out-of-tree builds. This causes such builds to fail since `pthread` isn't being correctly linked. This patch attempts to fix that problem by renaming and exporting `LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB` because It seemed likely to cause collisions with downstream users of `LLVMConfig.cmake`. llvm-svn: 294690
2017-02-10 02:59:20 +01:00
find_library(LLVM_PTHREAD_LIBRARY_PATH pthread)
if (LLVM_PTHREAD_LIBRARY_PATH)
Use -Wl,defs when linking. ELF linkers by default allow shared libraries to contain undefined references and it is up to the dynamic linker to look for them. On COFF and MachO, that is not the case. This creates a situation where a .so might build on an ELF system, but the build of the corresponding .dylib or .dll will fail. This patch changes the cmake build to use -Wl,-z,defs when linking and updates the dependencies so that -DBUILD_SHARED_LIBS=ON build still works. llvm-svn: 226611
2015-01-20 22:23:15 +01:00
list(APPEND LIBS pthread)
endif()
Reverting "CMake: Don't include tools, unittets, or examples as available targets unless LLVM_INCLUDE_X is ON. LLVM_BUILD_X implies LLVM_INCLUDE_X" It breaks the configuration phase when cmake is invoked without parameters, it is too complex for the purpose and introduces an incovenience for the user (as both LLVM_BUILD_X and LLVM_INCLUDE_X must set to OFF for not including X on the build) llvm-svn: 114795
2010-09-25 22:25:25 +02:00
add_llvm_library(gtest
Move all of the GoogleTest files back to the same locations they occupy externally to simplify our integration of GoogleTest into LLVM. Also, build the single source file gtest-all.cc instead of the individual source files as we don't expect these to change and thus gain nothing from increased incrementality in compiles. This makes our standard build of googletest exactly like upstream's recommended build and the sanitizer's build. It also simplifies the steps of importing a new version should we ever want one. llvm-svn: 194801
2013-11-15 11:20:45 +01: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-10 23:32:26 +01:00
googlemock/src/gmock-all.cc
CMake: Build unittests. llvm-svn: 114725
2010-09-24 11:01:13 +02:00
[CMake] Use LINK_LIBS instead of target_link_libraries(). llvm-svn: 202238
2014-02-26 07:41:29 +01:00
LINK_LIBS
Use -Wl,defs when linking. ELF linkers by default allow shared libraries to contain undefined references and it is up to the dynamic linker to look for them. On COFF and MachO, that is not the case. This creates a situation where a .so might build on an ELF system, but the build of the corresponding .dylib or .dll will fail. This patch changes the cmake build to use -Wl,-z,defs when linking and updates the dependencies so that -DBUILD_SHARED_LIBS=ON build still works. llvm-svn: 226611
2015-01-20 22:23:15 +01:00
${LIBS}
Avoid linking LLVM component libraries with libLLVM Patch by Jack Howarth. When linking to libLLVM, don't also link to the component libraries that constitute libLLVM. Differential Revision: http://reviews.llvm.org/D16945 llvm-svn: 260641
2016-02-12 02:42:43 +01:00
LINK_COMPONENTS
Support # Depends on llvm::raw_ostream
[cmake] Export gtest/gtest_main and its dependencies via a special build tree only cmake exports file. Previously, gtest/gtest_main were not exported via cmake. The intention here was to ensure that users whom are linking against the LLVM install tree would not get the gtest/gtest_main targets. This prevents downstream projects that link against the LLVM build tree (i.e. Swift) from getting this dependency information in their cmake builds. Without such dependency information, linker issues can result on linux due to LLVMSupport being put before gtest on the linker command line. This commit preserves behavior that we want for the install tree, while adding support for the build tree by: 1. The special casing for gtest/gtest_main in the add_llvm_library code is removed in favor of a flag called "BUILDTREE_ONLY". If this is set, then the library is communicating that it is only meant to be exported into the build tree and is not meant to be installed or exported via the install tree. This part is just a tweak to remove the special case, the underlying code is the same. 2. The cmake code that exports cmake targets for the build tree has special code to import an additional targets file called LLVMBuildTreeOnlyExports.cmake. Additionally the extra targets are added to the LLVMConfig.cmake's LLVM_EXPORTED_TARGETS variable. In contrast, the "installation" cmake file uses the normal LLVM_EXPORTS_TARGETS as before and does not include the extra exports file. This is implemented by defining/undefining variables when performing a configure of the build/install tree LLVMConfig.cmake files. llvm-svn: 281085
2016-09-09 21:45:34 +02:00
# This is a library meant only for the build tree.
BUILDTREE_ONLY
Use -Wl,defs when linking. ELF linkers by default allow shared libraries to contain undefined references and it is up to the dynamic linker to look for them. On COFF and MachO, that is not the case. This creates a situation where a .so might build on an ELF system, but the build of the corresponding .dylib or .dll will fail. This patch changes the cmake build to use -Wl,-z,defs when linking and updates the dependencies so that -DBUILD_SHARED_LIBS=ON build still works. llvm-svn: 226611
2015-01-20 22:23:15 +01:00
)
[CMake] Add dependencies to gtest. llvm-svn: 201079
2014-02-10 12:27:41 +01:00
Use INTERFACE_COMPILE_OPTIONS to disable -Wsuggest-override for any target that links to gtest This cleans up several CMakeLists.txt's where -Wno-suggest-override was manually specified. These test targets now inherit this flag from the gtest target. Some unittests CMakeLists.txt's, in particular Flang and LLDB, are not touched by this patch. Flang manually adds the gtest sources itself in some configurations, rather than linking to LLVM's gtest target, so this fix would be insufficient to cover those cases. Similarly, LLDB has subdirectories that manually add the gtest headers to their include path without linking to the gtest target, so those subdirectories still need -Wno-suggest-override to be manually specified to compile without warnings. Differential Revision: https://reviews.llvm.org/D84554
2020-07-27 17:37:01 +02: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()
[cmake] Make gtest macro definitions a part the library interface These definitions are needed by any file which uses gtest. Previously we were adding them in the add_unittest function, but over time we've accumulated libraries (which don't go through add_unittest) building on gtest and this has resulted in proliferation of the definitions. Making this a part of the library interface enables them to be managed centrally. This follows a patch for -Wno-suggest-override (D84554) which took a similar approach. Differential Revision: https://reviews.llvm.org/D84748
2020-07-28 15:26:23 +02:00
if (NOT LLVM_ENABLE_THREADS)
target_compile_definitions(gtest PUBLIC GTEST_HAS_PTHREAD=0)
endif ()
[cmake] Make gtest include directories a part of the library interface This applies the same fix that D84748 did for macro definitions. Appropriate include path is now automatically set for all libraries which link against gtest targets, which avoids the need to set include_directories in various parts of the project. Differential Revision: https://reviews.llvm.org/D86616
2020-08-12 12:02:37 +02:00
target_include_directories(gtest
PUBLIC googletest/include googlemock/include
PRIVATE googletest googlemock
)
Sink add_llvm_library(gtest_main) to UnitTestMain/CMakeLists.txt. llvm-svn: 198933
2014-01-10 12:02:26 +01: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 04:15:07 +01: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)
Reference in New Issue Copy Permalink