summaryrefslogtreecommitdiffstats
path: root/llvm/utils/unittest/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Make most target symbols hidden by defaultTom Stellard2020-01-141-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert CMake: Make most target symbols hidden by defaultTom Stellard2019-06-111-20/+0
| | | | | | | | | | | | | | | This reverts r362990 (git commit 374571301dc8e9bc9fdd1d70f86015de198673bd) This was causing linker warnings on Darwin: ld: warning: direct access in function 'llvm::initializeEvexToVexInstPassPass(llvm::PassRegistry&)' from file '../../lib/libLLVMX86CodeGen.a(X86EvexToVex.cpp.o)' to global weak symbol 'void std::__1::__call_once_proxy<std::__1::tuple<void* (&)(llvm::PassRegistry&), std::__1::reference_wrapper<llvm::PassRegistry>&&> >(void*)' from file '../../lib/libLLVMCore.a(Verifier.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. llvm-svn: 363028
* CMake: Make most target symbols hidden by defaultTom Stellard2019-06-101-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Jim, hiraditya, michaelplatings, chapuni, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, 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 llvm-svn: 362990
* Build with _XOPEN_SOURCE defined on AIXDavid Tenty2019-06-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Force #define GTEST_LANG_CXX11.Zachary Turner2017-10-271-0/+5
| | | | | | | | | | | | | | | | | | gtest depends on this #define to determine whether it can use various classes like std::tuple, or whether it has to fall back to experimental classes in the std::tr1 namespace. The check in the current version of gtest relies on the value of the `__cplusplus` macro, but MSVC provides a non-conformant value of this macro, making it effectively impossible to detect C++11. In short, LLVM compiled with MSVC has been silently using the tr1 versions of several classes since the beginning of time. This would normally be pretty benign, except that in the latest preview of MSVC they have marked all of the tr1 classes deprecated, so it spews thousands of warnings. llvm-svn: 316798
* [CMake] Fix pthread handling for out-of-tree buildsEric Fiselier2017-02-101-2/+2
| | | | | | | | | | | | | | | 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
* Add the 'googlemock' component of Google Test to LLVM's unittest libraries.Chandler Carruth2017-01-101-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [gtest] Detect warning flags using the positive spelling.Chandler Carruth2017-01-061-2/+2
| | | | | | | | | | | | | | | | | | | | | 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
* [gtest] Upgrade googletest to version 1.8.0, minimizing local changes.Chandler Carruth2017-01-041-0/+6
| | | | | | | | | 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
* [cmake] Export gtest/gtest_main and its dependencies via a special build ↵Michael Gottesman2016-09-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Avoid linking LLVM component libraries with libLLVMAndrew Wilkins2016-02-121-4/+3
| | | | | | | | | | | 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
* Reapply r229185(cbieneman) -- Raising minimum required Visual Studio version ↵NAKAMURA Takumi2015-02-151-6/+0
| | | | | | | | to 2013. This is based on the discussions on: [LLVMdev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk llvm-svn: 229320
* Revert r229185, "Raising minimum required Visual Studio version to 2013."NAKAMURA Takumi2015-02-141-0/+6
| | | | | | All builders are not ready yet. llvm-svn: 229199
* Raising minimum required Visual Studio version to 2013.Chris Bieneman2015-02-131-6/+0
| | | | | | This is based on the discussions on: [LLVMdev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk llvm-svn: 229185
* Use -Wl,defs when linking.Rafael Espindola2015-01-201-2/+11
| | | | | | | | | | | | | | | 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
* [CMake] Use LINK_LIBS instead of target_link_libraries().NAKAMURA Takumi2014-02-261-4/+2
| | | | llvm-svn: 202238
* [CMake] Add dependencies to gtest.NAKAMURA Takumi2014-02-101-0/+5
| | | | llvm-svn: 201079
* Sink add_llvm_library(gtest_main) to UnitTestMain/CMakeLists.txt.NAKAMURA Takumi2014-01-101-3/+1
| | | | llvm-svn: 198933
* Move all of the GoogleTest files back to the same locations they occupyChandler Carruth2013-11-151-7/+2
| | | | | | | | | | | | | 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
* Get the unittests compiling when building with cmake and the settingDuncan Sands2013-05-141-0/+4
| | | | | | -DLLVM_ENABLE_THREADS=false. llvm-svn: 181788
* Fix gtest build issue on Visual Studio 2012 RCJustin Holewinski2012-06-061-0/+6
| | | | llvm-svn: 158046
* build/CMake: Finish removal of add_llvm_library_dependencies.Daniel Dunbar2011-11-291-8/+0
| | | | llvm-svn: 145420
* Adding dependencies to allow -DBUILD_SHARED_LIBS=true to complete.Joe Abbey2011-10-191-0/+8
| | | | llvm-svn: 142464
* Update CMake build for new gtest file.Frits van Bommel2011-07-271-0/+1
| | | | llvm-svn: 136215
* Fix VC2010 build.Michael J. Spencer2010-10-191-3/+0
| | | | llvm-svn: 116833
* Build with RTTI and exceptions disabled. Only in GCC for now.Oscar Fuentes2010-10-171-0/+6
| | | | llvm-svn: 116682
* CMake: Fix warning in gtest.Michael J. Spencer2010-10-071-0/+4
| | | | llvm-svn: 115935
* Reverting "CMake: Don't include tools, unittets, or examples asOscar Fuentes2010-09-251-13/+11
| | | | | | | | | | | | 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
* CMake: Don't include tools, unittets, or examples as available targetsMichael J. Spencer2010-09-241-11/+13
| | | | | | unless LLVM_INCLUDE_X is ON. LLVM_BUILD_X implies LLVM_INCLUDE_X llvm-svn: 114747
* CMake: Build unittests.Michael J. Spencer2010-09-241-0/+34
llvm-svn: 114725
OpenPOWER on IntegriCloud