summaryrefslogtreecommitdiffstats
path: root/llvm/cmake/modules
Commit message (Collapse)AuthorAgeFilesLines
...
* Add the 'googlemock' component of Google Test to LLVM's unittest libraries.Chandler Carruth2017-01-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [cmake] Canonicalize CMake booleans to 0/1 for lit interopMichal Gorny2017-01-061-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Canonicalize all CMake booleans to 0/1 before passing them to lit, to ensure that the Python side handles all of them consistently and correctly. 0/1 is a safe choice of values that trigger the same boolean interpretation in CMake, Python and C++. Furthermore, using them without quotes improves the chance Python will explicitly fail when an incorrect value (such as ON/OFF, TRUE/FALSE, YES/NO) is accidentally passed, rather than silently misinterpreting the value. This replaces a lot of different logics spread around lit site files, attempting to partially reproduce the boolean logic used in CMake and usually silently failing when an uncommon value was used instead. In fact, some of them were never working correctly since different values were assigned in CMake and checked in Python. The alternative solution could be to create a common parser for CMake booleans in lit and use it consistently throughout the site files. However, it does not seem like the best idea to create redundant implementation of the same logic and have to follow upstream if it ever is extended to handle more values. Differential Revision: https://reviews.llvm.org/D28294 llvm-svn: 291284
* [gtest] Fix the way we disable a warning for unittests.Chandler Carruth2017-01-041-0/+4
| | | | | | | | I somehow wrote this fix and then lost it prior to commit. Really sorry about the noise. This should fix some issues with hacking add_definition to do things with warning flags. llvm-svn: 291033
* Fix the MSVC version check.Zachary Turner2017-01-031-2/+2
| | | | | | | | | | I'm not sure what determines the minor version, but it appears that it's possible for a fully updated, release version of VS2015 with Update 3 can go (at least) as low as 19.00.24213.1. Updating the compiler version check to account for this so we don't generate superfluous warnings. llvm-svn: 290914
* [cmake] Add LLVM_ENABLE_DIA_SDK option, and expose it in LLVMConfigMichal Gorny2017-01-021-0/+2
| | | | | | | | | | | | | | | Add an explicit LLVM_ENABLE_DIA_SDK option to control building support for DIA SDK-based debugging. Control its value to match whether DIA SDK support was found and expose it in LLVMConfig (alike LLVM_ENABLE_ZLIB). Its value is needed for LLDB to determine whether to run tests requiring DIA support. Currently it is obtained from llvm/Config/config.h; however, this file is not available for standalone builds. Following this change, LLDB will be modified to use the value from LLVMConfig. Differential Revision: https://reviews.llvm.org/D26255 llvm-svn: 290818
* Enable '-Wstring-conversion' and fix some bad asserts that it helpedChandler Carruth2016-12-231-0/+3
| | | | | | | | find. Notable is the assert in NewGVN which had no effect because of the bug. llvm-svn: 290400
* Pass -Wa,-mbig-obj in 64-bit mingw buildsReid Kleckner2016-12-221-0/+7
| | | | | | | | | | | COFF has a 2**16 section limit, and on Win64, every COMDAT function creates at least 3 sections: .text, .pdata, and .xdata. For MSVC, we enable bigobj on a file-by-file basis, but GCC appears to hit the limit on different files. Fixes PR25953 llvm-svn: 290358
* Fix some remaining documentation references to MSVC 2013Reid Kleckner2016-12-151-7/+7
| | | | | | | | MSVC 2015 has been the minimum supported version of VS since October. Differential Revision: https://reviews.llvm.org/D25710 llvm-svn: 289854
* [CMake] Minor change to symlink generation for LLDBChris Bieneman2016-12-151-2/+7
| | | | | | | | If OUTPUT_DIR is not specified we can assume the symlink is linking to a file in the same directory, so we can use $<TARGET_FILE_NAME:${target}> to create a relative symlink. In the case of LLDB, when we build a framework, we are creating symlinks in a different directory than the file we're pointing to, and we don't install those links. To make this work in the build directory we can use $<TARGET_FILE:${target}> instead, which uses the full path to the target. llvm-svn: 289840
* [CMake] Multi-target builtins buildPetr Hosek2016-12-121-0/+9
| | | | | | | | | | | | | | This change enables building builtins for multiple different targets using LLVM runtimes directory. To specify the builtin targets to be built, use the LLVM_BUILTIN_TARGETS variable, where the value is the list of targets. To pass a per target variable to the builtin build, you can set BUILTINS_<target>_<variable> where <variable> will be passed to the builtin build for <target>. Differential Revision: https://reviews.llvm.org/D26652 llvm-svn: 289491
* [libFuzzer] switch all libFuzzer tests to use ↵Kostya Serebryany2016-12-101-1/+1
| | | | | | -fsanitize-coverage=trace-pc-guard. Support for the previosly used instrumentation will be removed in the following changes llvm-svn: 289311
* Remove /Zc:sizedDealloc- from the MSVC buildReid Kleckner2016-12-091-5/+0
| | | | | | | | | | According to the connect bug (https://connect.microsoft.com/VisualStudio/feedback/details/1351894), this was only necessary with pre-release versions of MSVC 2015. Fixes PR23513 llvm-svn: 289257
* [CMake] Fixing clang standalone buildChris Bieneman2016-12-061-0/+4
| | | | | | I broke this in r288770. llvm-svn: 288829
* [CMake] Cleanup TableGen include flagsChris Bieneman2016-12-061-10/+4
| | | | | | | | | | It is kinda crazy to have llvm/include and llvm/lib/Target in the include path for every tablegen invocation for every tablegen-like tool. This patch removes those flags from the tablgen function that is called everywhere by instead creating a variable LLVM_TABLEGEN_FLAGS which is setup in the LLVM source directories. This removes TableGen.cmake's dependency on LLVM_MAIN_SRC_DIR, and LLVM_MAIN_INCLUDE_DIR. llvm-svn: 288770
* [CMake] Fix symlink refactor for multi-configuration generatorsChris Bieneman2016-12-051-3/+23
| | | | | | This fix, while a bit complicated, preserves the reusability while fixing the issues reported on llvm-commits with visual studio generators. llvm-svn: 288679
* [cmake] Include component in Sphinx install rulesMichal Gorny2016-12-051-0/+2
| | | | | | | | | Include component in install rules for Sphinx targets. Based on a similar suggestion for other doc targets in D24935. Differential Revision: https://reviews.llvm.org/D24982 llvm-svn: 288656
* [CMake] Refactor add_llvm_tool_symlink for reuseChris Bieneman2016-12-051-13/+24
| | | | | | The old implementation of add_llvm_tool_symlink could fail in odd ways when building out of tree. This version solves that problem by not using the LLVM_* variables, and instead reaeding the target's properties. llvm-svn: 288632
* build: allow specifying the component to `llvm_install_symlink`Saleem Abdulrasool2016-12-031-4/+8
| | | | | | | | Add an optional parameter to `llvm_install_symlink` which allows the symlink installation to be placed into a specific component rather than the default value. llvm-svn: 288600
* cmake: Set rpath for loadable modules as well as shared libraries.Peter Collingbourne2016-11-281-0/+1
| | | | | | | | | | | This fixes a regression introduced by r285714: we weren't setting the rpath on LLVMgold.so correctly. Spotted by mark@chromium.org! Differential Revision: https://reviews.llvm.org/D27176 llvm-svn: 288076
* [CMake] Apply sandbox profile to target not directoryChris Bieneman2016-11-191-5/+5
| | | | | | When LLVM_DEPENDENCY_DEBUGGING=On we should apply the sandbox only on the target, not the directory. This is important for directories that create more than one target, or for nested directories. llvm-svn: 287415
* [CMake] Error when LTO and lld are enabled on DarwinPetr Hosek2016-11-171-0/+3
| | | | | | | | lld on Darwin does not currently support LTO. Differential Revision: https://reviews.llvm.org/D26715 llvm-svn: 287256
* [cmake] Move LLVM_BUILD_STATIC check to an earlier pointPavel Labath2016-11-171-4/+0
| | | | | | | | | | | | | | | | | | | | Summary: The motivation for this is to enable correct detection of dlopen() on Android. Android does not provide a static version of libdl, so if we add the -static flag after performing the check, it will succeed even though subsequent link steps will fail. With this change we correctly detect the absence of libdl in a LLVM_BUILD_STATIC build on Android. The link itself still does not succeed because the code does not check the result of this check properly, but I plan to fix that in a separate change. Reviewers: beanz Subscribers: danalbert, mgorny, srhines, tberghammer, llvm-commits Differential Revision: https://reviews.llvm.org/D26463 llvm-svn: 287220
* [CMake] [Darwin] Add support for debugging tablegen dependenciesChris Bieneman2016-11-171-1/+23
| | | | | | | | This patch adds an option to the build system LLVM_DEPENDENCY_DEBUGGING. Over time I plan to extend this to do more complex verifications, but the initial patch causes compile errors wherever there is missing a dependency on intrinsics_gen. Because intrinsics_gen is a compile-time dependency not a link-time dependency, everything that relies on the headers generated in intrinsics_gen needs an explicit dependency. llvm-svn: 287207
* Reverting r285406, which was a temporary workaround to get one of the ↵Aaron Ballman2016-11-141-5/+3
| | | | | | documentation bots upgraded to something newer than GCC 4.7. This restores the check for GCC 4.8. llvm-svn: 286822
* CMake: make LLVM_OPTIMIZED_TABLEGEN friendly with LLVM_EXTERNAL_CLANG_SOURCE_DIRMehdi Amini2016-11-111-0/+5
| | | | | | | | This is need because of clang-tblgen Differential Revision: https://reviews.llvm.org/D26483 llvm-svn: 286560
* cmake: Don't try to install exports if there aren't anyJustin Bogner2016-11-082-2/+8
| | | | | | | | | When using LLVM_DISTRIBUTION_COMPONENTS, it's possible for LLVM's export list to be empty. If this happens the install(EXPORTS) command will fail, but since there isn't anything to install anyway we really just want to skip it. llvm-svn: 286209
* [CMake] Fix llvm_setup_rpath functionMandeep Singh Grang2016-11-081-16/+16
| | | | | | | | | | | | | | | | | | | Summary: Set _install_rpath to CMAKE_INSTALL_RPATH if it is defined, so that eventually INSTALL_RPATH is set to CMAKE_INSTALL_RPATH. The "if(NOT DEFINED CMAKE_INSTALL_RPATH)" was missing a corresponding else clause. This also cleans up the fix made in r285908. Patch by Azharuddin Mohammed Reviewers: john.brawn, sgundapa, beanz Subscribers: chapuni, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D26289 llvm-svn: 286184
* cmake: When using LLVM_DISTRIBUTION_COMPONENTS, adjust LLVMExports accordinglyJustin Bogner2016-11-042-8/+29
| | | | | | | This Makes sure we only export targets that we're distributing, since cmake will fail to import the file otherwise due to missing targets. llvm-svn: 286024
* [CMake] Make CMAKE_INSTALL_RPATH work againJohn Brawn2016-11-031-4/+6
| | | | | | | | r285714 made it so that when CMAKE_INSTALL_RPATH is set _install_rpath is not set, but that means INSTALL_RPATH gets set to an empty string which isn't what we want. Fix this by setting INSTALL_RPATH only when _install_rpath is set. llvm-svn: 285908
* [CMake] Disable rpath for UnitTestsJonas Hahnfeld2016-11-031-3/+5
| | | | | | | | This was broken since rL285714. Differential Revision: https://reviews.llvm.org/D26246 llvm-svn: 285881
* [CMake] Fix rpath construction for out-of-tree buildsChris Bieneman2016-11-011-0/+37
| | | | | | | | This patch was produced in conjunction with Michał Górny. It should resolve the issues that were trying to be solved by D25304. This moves rpath handling into `llvm_add_library` and `add_llvm_executable` so that it is available to all projects using AddLLVM whether built in-tree or out-of-tree. llvm-svn: 285714
* cmake: Enable the lto cache when building with -flto=thin on darwinJustin Bogner2016-10-281-0/+5
| | | | llvm-svn: 285450
* [cmake] Temporarily revert enforcement of minimum GCC version increaseTeresa Johnson2016-10-281-3/+5
| | | | | | | | | | | | | | | Summary: This is temporary, until bot that builds public facing LLVM documentation is upgraded. It reverts only the cmake change in r284497, but leaves the doc changes in place to preserve intent. Reviewers: aaron.ballman Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D26078 llvm-svn: 285406
* cmake: Make /usr/share/cmake installable with LLVM_DISTRIBUTION_COMPONENTSJustin Bogner2016-10-241-2/+14
| | | | | | | Add a cmake-exports install component and appropriate targets for LLVM_DISTRIBUTION_COMPONENTS to work with. llvm-svn: 285030
* [docs] Increase minimum supported GCC version for building LLVM to 4.8Teresa Johnson2016-10-181-4/+4
| | | | | | | | | | | | | | | | | | | | Summary: The RFC proposal sent to increase the minimum required GCC version to 4.8 received a lot of support. See the following thread: http://lists.llvm.org/pipermail/llvm-dev/2016-October/105955.html, This patch implements that by updating the docs. I believe the references to libstdc++ 4.7 issues can be removed as well, please let me know if that is not the case or if they should be updated a different way. Reviewers: rengolin Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25683 llvm-svn: 284497
* [cmake] Make LIT_COMMAND configurable and improve fallback supportMichal Gorny2016-10-041-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make LIT_COMMAND configurable, use source tree only when actually available and extend the default search to other common executable names 'lit.py' and 'lit', in order to increase uniformity between all LLVM projects and support using installed lit. Changing the conditional used to determine whether in-tree or external lit is being used covers the case when LLVM_MAIN_SRC_DIR is defined but does not exist (anymore). In this case, the functions falls back to looking for installed lit rather than attempting to use a non-existing path. The same conditional is used in clang already. Making LIT_COMMAND a cache variable in case the source tree variant is used serves two purposes. Firstly, it increases uniformity between the two branches since find_program() implicitly makes LIT_COMMAND a cache variable. Secondly, it allows overriding the lit executable used to run the tests when the LLVM source tree is provided. Gentoo is planning to use this to use installed (and byte-compiled) lit instead of re-compiling it in every LLVM project. Extending default search is meant to increase uniformity between different LLVM projects. The 'lit.py' name is already used by a few of them, and 'lit' is the name used by utils/lit/setup.py when installing. Differential Revision: https://reviews.llvm.org/D25076 llvm-svn: 283247
* [CMake] Exclude intrinsics_gen from LLVM_COMMON_DEPENDS in LLVMConfig.cmakeChris Bieneman2016-10-041-0/+9
| | | | | | CMake requires that all targets expressed as dependencies exist, so we can't have intrinsics_gen in LLVM_COMMON_DEPENDS when it is written out, otherwise projects building out of tree will have CMake errors. llvm-svn: 283234
* [cmake] Reintroduce (ldconfig-compatible) SOVERSIONs on shared librariesMichal Gorny2016-10-041-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reintroduce versioning of shared libraries via SOVERSION, addressing the issues with the previous design, since Gentoo is relying on shared-split install of LLVM. The SOVERSIONs were originally introduced in r229720 for all libraries, and removed in r252093 in favor of custom SONAME. As far as I understand, the major concern with the old versioning was that the used versions were incompatible with ldconfig. Having considered that, this commit introduce SOVERSIONS with the following considerations: 1. SOVERSIONs are formed of major & minor version concatenated -- i.e. for 4.0 its .so.40. This matches the common practice where the first version number indicates ABI breakage, and therefore fixes the issues with ldconfig. Additionally, VERSION with the remaining verion components appended is used, however this is not strictly necessary. 2. The versioning is only applied to libraries with no explicit SONAME specified -- i.e. it won't apply to libLLVM but only to the split libraries. It will also apply to libraries installed by the subprojects. 3. The versioning is only done on *nix systems, Darwin excluded. This matches the current use of SONAME. Differential Revision: https://reviews.llvm.org/D24757 llvm-svn: 283189
* [cmake] Use separate doctrees to prevent races between Sphinx instancesMichal Gorny2016-10-041-1/+1
| | | | | | | | | | | | Use separate doctrees between different Sphinx builders in order to prevent race condition issues due to multiple Sphinx instances accessing the same doctree cache in parallel. Bug: https://llvm.org/bugs/show_bug.cgi?id=23781 Differential Revision: https://reviews.llvm.org/D23755 llvm-svn: 283188
* Revert r283029 - [cmake] Make LIT_COMMAND configurable and improve fallback ↵Michal Gorny2016-10-011-4/+3
| | | | | | | | | | | | | | support Revert the change in r283029 (and the fixup in r283033) due to buildbot breakage. The fixup is ineffective for the bots that do not force clean build since the wrong value is already cached in CMakeCache.txt. Reverting it should result in the cache variable being removed and therefore it should be possible to re-introduce it after all buildbots build this revision. llvm-svn: 283036
* [cmake] Fix incorrect default for LIT_COMMAND, from r283029Michal Gorny2016-10-011-1/+1
| | | | llvm-svn: 283033
* [cmake] Make LIT_COMMAND configurable and improve fallback supportMichal Gorny2016-10-011-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make LIT_COMMAND configurable, use source tree only when actually available and extend the default search to other common executable names 'lit.py' and 'lit', in order to increase uniformity between all LLVM projects and support using installed lit. Changing the conditional used to determine whether in-tree or external lit is being used covers the case when LLVM_MAIN_SRC_DIR is defined but does not exist (anymore). In this case, the functions falls back to looking for installed lit rather than attempting to use a non-existing path. The same conditional is used in clang already. Making LIT_COMMAND a cache variable in case the source tree variant is used serves two purposes. Firstly, it increases uniformity between the two branches since find_program() implicitly makes LIT_COMMAND a cache variable. Secondly, it allows overriding the lit executable used to run the tests when the LLVM source tree is provided. Gentoo is planning to use this to use installed (and byte-compiled) lit instead of re-compiling it in every LLVM project. Extending default search is meant to increase uniformity between different LLVM projects. The 'lit.py' name is already used by a few of them, and 'lit' is the name used by utils/lit/setup.py when installing. Differential Revision: https://reviews.llvm.org/D25076 llvm-svn: 283029
* [OCaml] Install .mli (interface) filesMichal Gorny2016-10-011-1/+2
| | | | | | | | | | | | | Install the OCaml interface .mli files. Those files were most likely omitted because they are input files for the compiled .cmi files. However, installing them is reasonable since -- unlike .cmi files -- they are human-readable. The issue was originally spotted by @jpdeplaix. Differential Revision: https://reviews.llvm.org/D25128 llvm-svn: 283028
* cmake: Install the OCaml libraries into a more correct pathMichal Gorny2016-09-301-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a OCAML_INSTALL_PATH variable that can be used to control the install path for OCaml libraries. The new variable defaults to ${OCAML_STDLIB_PATH}, i.e. the OCaml library path obtained from the OCaml compiler. Install libraries into "llvm" subdirectory. This fixes two issues: 1. OCaml library directories differ between systems, and 'lib/ocaml' is incorrect e.g. on amd64 Gentoo where OCaml is installed in 'lib64/ocaml'. Therefore, obtain the library path from the OCaml compiler using 'ocamlc -where' (which is already used to set OCAML_STDLIB_PATH), which is the method used commonly in OCaml packages. 2. The top-level directory is reserved for the standard library, and has precedence over local directory in search path. As a result, OCaml preferred the files installed along with previous LLVM version over the source tree when building a new version, resulting in two versions being mixed during the build. The new layout is used commonly by other OCaml packages, and findlib is able to find the LLVM libraries successfully. Bug: https://bugs.gentoo.org/559134 Bug: https://bugs.gentoo.org/559624 Differential Revision: https://reviews.llvm.org/D24354 llvm-svn: 282895
* [CMake] Support symlinks even with LLVM_INSTALL_TOOLCHAIN_ONLYPetr Hosek2016-09-301-3/+3
| | | | | | | | | | When LLVM_INSTALL_TOOLCHAIN_ONLY is used and LLVM_TOOLCHAIN_TOOLS contains a tool which is a symlink, it would be ignored. This already worked before but got broken in r282510. Differential Revision: https://reviews.llvm.org/D25067 llvm-svn: 282844
* [modules] Centralize the module cache.Vassil Vassilev2016-09-291-1/+1
| | | | | | This reduces the build size from 17G to 1.9G on my machine. llvm-svn: 282704
* Improve CMake output of host and target tripleChris Bieneman2016-09-271-1/+0
| | | | | | | | | | | | | | | | | Summary: The previous output was confusing as it would output "Taget triple: x86_64-unknown-linux-gnu" even when LLVM_HOST_TRIPLE or LLVM_DEFAULT_TARGET_TRIPLE were set on the CMake command line Patch by: Alex Richardson! Reviewers: beanz Subscribers: Eugene.Zelenko Differential Revision: https://reviews.llvm.org/D17067 llvm-svn: 282516
* [CMake] Use if(... IN_LIST ...) instead of list(FIND...)Chris Bieneman2016-09-271-14/+6
| | | | | | NFC. This is just a little code cleanup to make things easier to read and understand. llvm-svn: 282510
* cmake: Support overriding Sphinx HTML doc install directoryMichal Gorny2016-09-231-2/+9
| | | | | | | | | | | | Provide ${PROJECT}_INSTALL_SPHINX_HTML_DIR variables (e.g. LLVM_INSTALL_SPHINX_HTML_DIR) to override Sphinx HTML doc install directory. Bug: https://llvm.org/bugs/show_bug.cgi?id=23780 Differential Revision: https://reviews.llvm.org/D23757 llvm-svn: 282240
OpenPOWER on IntegriCloud