summaryrefslogtreecommitdiffstats
path: root/llvm/cmake/modules
Commit message (Collapse)AuthorAgeFilesLines
...
* [cmake] Make linker detection take flags into accountShoaib Meenai2018-04-261-1/+2
| | | | | | | | | | | | LLVM might be compiled using a toolchain file which controls the linker to use via flags (e.g. `-B` or `-fuse-ld=`). Take these flags into account for linker detection. We can also correct the detection by manually passing LLVM_USE_LINKER, of course, but it seems more convenient to have the detection take flags into account. Differential Revision: https://reviews.llvm.org/D45464 llvm-svn: 330924
* Rename Attributes.gen, Intrinsics.gen to Attributes.inc, Intrinsics.incNico Weber2018-04-251-3/+3
| | | | | | | | | Virtually all other tablegen outputs are called .inc, not .gen, so rename these two too for consistency. No behavior change. https://reviews.llvm.org/D46058 llvm-svn: 330843
* [cmake] Fix libc++ detectionShoaib Meenai2018-04-241-2/+4
| | | | | | | | | | | -stdlib=libc++ is added to both the compilation and the link flags, but the logic for adding it was only checking if it was supported during compilation and not linking. This could lead to false positives, for example when using clang with libstdc++ (where the compiler would support -stdlib=libc++ but then linking would fail because of libc++ actually being unavailable). llvm-svn: 330761
* Let TableGen write output only if it changed, instead of doing so in cmake.Nico Weber2018-04-241-16/+4
| | | | | | | | | | | Removes one subprocess and one temp file from the build for each tablegen invocation. No intended behavior change. https://reviews.llvm.org/D45899 llvm-svn: 330742
* Revert "build: reserve `--color-diagnostics` for lld"Saleem Abdulrasool2018-04-161-1/+1
| | | | | | | | | | | | This reverts SVN r330158. Seems that there was a change to linker flags handling in SVN r316972. That would alter the behaviour to correct the linker flag handling in CMake (requiring CMake 3.4.3+). Since that is already the minimum version required for LLVM, hard coding the knowledge of the linker is not required, which is a strictly better solution. llvm-svn: 330161
* build: reserve `--color-diagnostics` for lldSaleem Abdulrasool2018-04-161-1/+1
| | | | | | | | | | When building out-of-tree compilers (e.g. swift), the linker check here may yield incorrect values. Ensure that we are using lld before we attempt to use `--color-diagnostics` for the linker. Other linkers (i.e bfd, gold) do not support this flag and the test can pass in some cases and then fail subsequently when building. llvm-svn: 330158
* [Build][NFC] Split off libpfm detection to a separate module.Clement Courbet2018-04-111-0/+23
| | | | llvm-svn: 329783
* Rename llvm library from libLLVM-X.Y to libLLVM-XSylvestre Ledru2018-03-291-3/+3
| | | | | | | | | | | | | | | | | | Summary: As we are only doing X.0.Z releases (not using the minor version), there is no need to keep -X.Y in the version. Like patch https://reviews.llvm.org/D41808, I propose that we rename libLLVM-7.0svn.so to libLLVM-7svn.so This patch will also rename downstream libraries like liblldb-7.0 to liblldb-7 Reviewers: axw, beanz, dim, hans Reviewed By: dim, hans Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D41869 llvm-svn: 328768
* Accept any filepath in llvm_check_source_file_listSerge Guelton2018-03-191-4/+14
| | | | | | | | | | | Cmake function llvm_check_source_file_list currently only accepts paths relative to current CMAKE_SOURCE_DIR or relative to argument SOURCE_DIR. Extend it to accept any path, including absolute ones. Differential revision: https://reviews.llvm.org/D44625 llvm-svn: 327912
* Export LLVM_DYLIB_COMPONENTS in LLVMConfig.cmakePavel Labath2018-03-141-0/+2
| | | | | | | | | | | | | | | | | Summary: This is needed so that external projects (e.g. a standalone build of lldb) can link to the LLVM shared library via the USE_SHARED argument of llvm_config. Without this, llvm_config would add LLVM to the link list, but then also add the constituent static libraries, resulting in multiply defined symbols. Reviewers: beanz, mgorny Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44391 llvm-svn: 327484
* [cmake] Append -Wl,-rpath-link conditionally to GNULDMichal Gorny2018-03-081-1/+2
| | | | | | | | | | | | | | | Append -Wl,-rpath-link conditionally to whether GNU ld.bfd is used rather than the Linux+!gold conditionals. Also move it out of 'else' branch of *BSD handling. This fixes build failures with ld.bfd on Gentoo/FreeBSD, and should cause no harm on other systems using ld.bfd. This patch improves the original logic by reusing results of linker detection introduced in r307852. Differential Revision: https://reviews.llvm.org/D43751 llvm-svn: 327007
* Fix cmake's multi-config generators after r326738Daniel Sanders2018-03-071-3/+1
| | | | | | | LLVM_ENABLE_STATS isn't known at configure-time in these generators so we must defer it to build-time. llvm-svn: 326936
* Re-commit: Make STATISTIC() values available programmaticallyDaniel Sanders2018-03-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: It can be useful for tools to be able to retrieve the values of variables declared via STATISTIC() directly without having to emit them and parse them back. Use cases include: * Needing to report specific statistics to a test harness * Wanting to post-process statistics. For example, to produce a percentage of functions that were fully selected by GlobalISel Make this possible by adding llvm::GetStatistics() which returns an iterator_range that can be used to inspect the statistics that have been touched during execution. When statistics are disabled (NDEBUG and not LLVM_ENABLE_STATISTICS) this method will return an empty range. This patch doesn't address the effect of multiple compilations within the same process. In such situations, the statistics will be cumulative for all compilations up to the GetStatistics() call. Reviewers: qcolombet, rtereshin, aditya_nandakumar, bogner Reviewed By: rtereshin, bogner Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D43901 This re-commit fixes a missing include of <vector> which it seems clang didn't mind but G++ and MSVC objected to. It seems that, clang was ok with std::vector only being forward declared at the point of use since it was fully defined eventually but G++/MSVC both rejected it at the point of use. llvm-svn: 326738
* Revert r326723: Make STATISTIC() values available programmaticallyDaniel Sanders2018-03-051-4/+0
| | | | | | Despite building cleanly on my machine in three separate configs, it's failing on pretty much all bots due to missing includes among other things. Investigating. llvm-svn: 326726
* Make STATISTIC() values available programmaticallyDaniel Sanders2018-03-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: It can be useful for tools to be able to retrieve the values of variables declared via STATISTIC() directly without having to emit them and parse them back. Use cases include: * Needing to report specific statistics to a test harness * Wanting to post-process statistics. For example, to produce a percentage of functions that were fully selected by GlobalISel Make this possible by adding llvm::GetStatistics() which returns an iterator_range that can be used to inspect the statistics that have been touched during execution. When statistics are disabled (NDEBUG and not LLVM_ENABLE_STATISTICS) this method will return an empty range. This patch doesn't address the effect of multiple compilations within the same process. In such situations, the statistics will be cumulative for all compilations up to the GetStatistics() call. Reviewers: qcolombet, rtereshin, aditya_nandakumar, bogner Reviewed By: rtereshin, bogner Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D43901 llvm-svn: 326723
* Don't make PDBs by default in Release modeReid Kleckner2018-02-151-4/+11
| | | | | | | | | | | Introduce the LLVM_ENABLE_PDB option so that users can request them explicitly instead. Add /OPT:REF and /OPT:ICF back, which /DEBUG disables by default. Differential Revision: https://reviews.llvm.org/D43156 llvm-svn: 325296
* Generate PDB files for profiling even in Release build.Zachary Turner2018-02-071-0/+6
| | | | | | | | | | | | This patch enables PDB generation for Release build, which has slightly different optimize option with RelWithDebInfo on windows. This helps to know slow part of Release build when profiling. Patch by Takuto Ikuta Differential Revision: https://reviews.llvm.org/D42632 llvm-svn: 324504
* [cmake] Don't build Native llvm-config when cross compiling if passed by user.Don Hinton2018-01-211-1/+1
| | | | | | | | | | | | Summary: Rename LLVM_CONFIG_EXE to LLVM_CONFIG_PATH, and avoid building it if passed in by user. This is the same way CLANG_TABLEGEN and LLVM_TABLEGEN are handled, e.g., when -DLLVM_OPTIMIZED_TABLEGEN=ON is passed. Differential Revision: https://reviews.llvm.org/D41806 llvm-svn: 323053
* [cmake] Include LLVM_LIBXML2_ENABLED in LLVMConfig.cmake, PR36006Michal Gorny2018-01-191-0/+2
| | | | | | | | | | Include the LLVM_LIBXML2_ENABLED cache variable in LLVMConfig.cmake in order to make it available for other LLVM packages to query. This is necessary to fix stand-alone testing of LLD. Differential Revision: https://reviews.llvm.org/D42252 llvm-svn: 322973
* [CMake] Add LLVM_ENABLE_IDE option to better process sources for IDE'sEric Fiselier2018-01-122-1/+8
| | | | | | | | | | | | | | | | | | | | | Summary: Currently LLVM has no way to support configuring for IDE's like CLion. Like XCode and MSVC's IDE, CLion needs to see all of the headers and tablegen files in order to properly parse the sources. This patch adds an `LLVM_ENABLE_IDE` option which can be used to configure for IDE's in general. It is used by `LLVMProcessSources.cmake` to determine if the extra source files should be added to the target. Unfortunately because of the low level of `LLVMProcessSources.cmake`, I'm not sure where the `LLVM_ENABLE_IDE` option should live. I choose `HandleLLVMOptions.cmake` so that out-of-tree Clang builds would correctly configure the option by default. Reviewers: beanz, mgorny, lebedev.ri Reviewed By: beanz Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40219 llvm-svn: 322349
* [cmake] Use symlinks for Windows-hosted toolchains built on UnixShoaib Meenai2018-01-092-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When cross-compiling for Windows on Unix, the built toolchain will need to be transferred to Windows to actually run. My opinion is that the Unix build should use symlinks, and the transfer to Windows should take care of making those symlinks usable. E.g., I envision tarballs to be a common form of transfer from Unix to Windows, in which case the tarball can be created using --dereference to follow the symlinks. The motivation here is that, when cross-compiling for Windows on Unix, the installation will *already* create symlinks. The reason is that the installation script will be invoked without knowing the host system, so the `if(UNIX)` check in the installation symlink creation script will reflect the build system rather than the host system. We could either make the build and install trees both contain copies or both contain symlinks, and using symlinks is a significant space saving without (in my opinion) having any detrimental effect on the usage of the cross- compiled toolchain on Windows. A secondary motivation is that Windows 10 version 1703 and later finally lift the administrator rights requirement for creating symbolic links (if the system is in Developer Mode), which makes symlinks a lot more practical even on Windows. Of course Unix and Windows symlinks aren't interoperable, but symlinks for Windows toolchains is a reasonable future direction to be going in anyway. Differential Revision: https://reviews.llvm.org/D41314 llvm-svn: 322061
* [CMake] Support for cross-compilation when build runtimesPetr Hosek2018-01-082-2/+14
| | | | | | | | | | | When cross-compiling, we cannot use the just built toolchain, instead we need to use the host toolchain which we assume has a support for targeting the selected target platform. We also need to pass the path to the native version of llvm-config to external projects. Differential Revision: https://reviews.llvm.org/D41678 llvm-svn: 322046
* [cmake] Pass CMAKE_MAKE_PROGRAM to native configureShoaib Meenai2018-01-081-0/+1
| | | | | | | | | | | If the make program isn't in the path, the native configure will fail. Pass CMAKE_MAKE_PROGRAM to the native configure explicitly to remedy this, similar to what's already done for external project configuration. Explicitly set CMAKE_MAKE_PROGRAM before the user flags so that they can override it for the native build if they desire (though I can't fathom why that would be useful). llvm-svn: 322032
* [cmake] Always respect existing CMAKE_REQUIRED_FLAGS when adding additional ↵Don Hinton2017-12-252-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | ones. Summary: Always respect existing CMAKE_REQUIRED_FLAGS when adding additional ones. This is important when cross compiling where --sysroot and -target were already added. In particular, this is needed when cross compiling from Darwin to Linux, since --sysroot is required to find headers and libraries. Cmake has a similar bug in check_include_file[_cxx] where CMAKE_REQUIRED_LIBRARIES isn't passed, which causes try_compile to fail. (please see https://gitlab.kitware.com/cmake/cmake/merge_requests/1620) Reviewers: compnerd, silvas, beanz, brad.king Reviewed By: compnerd Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D41568 llvm-svn: 321434
* [CMake] Pass LLVM_HAVE_LINK_VERSION_SCRIPT to external projectsPetr Hosek2017-12-131-0/+1
| | | | | | | | Some external projects depend on this LLVM CMake variable. Differential Revision: https://reviews.llvm.org/D41205 llvm-svn: 320658
* [cmake] Determine MSVC host triple correctly when cross-compilingShoaib Meenai2017-12-131-1/+1
| | | | | | | | | | | | | | | | CMAKE_CL_64 will never be set when cross-compiling with clang-cl, since CMake relies on an actual VS environment in order to determine it. Instead, use the size of a void pointer to determine the bit width of the host compiler (and therefore the host triple), which works for both native and cross compilation. Note that, with the impending advent of Windows on AArch64, assuming that a 64-bit host == x86_64 isn't correct either, but that's something to be addressed in a follow-up. Differential Revision: https://reviews.llvm.org/D41155 llvm-svn: 320615
* [cmake] Fix host tools build in when LLVM_EXPERIMENTAL_TARGETS_TO_BUILD is setAlex Bradbury2017-12-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | r320413 triggered cmake configure failures when building with -DLLVM_OPTIMIZED_TABLEGEN=True and with LLVM_EXPERIMENTAL_TARGETS_TO_BUILD set (e.g. to RISCV). This is because that patch moved to passing through LLVM_TARGETS_TO_BUILD, and at that point LLVM_EXPERIMENTAL_TARGETS_TO_BUILD has been merged in to it. LLVM_EXPERIMENTAL_TARGETS_TO_BUILD must be also be passed through to avoid errors like below: -- Constructing LLVMBuild project information CMake Error at CMakeLists.txt:682 (message): The target `RISCV' does not exist. It should be one of AArch64;AMDGPU;ARM;BPF;Hexagon;Lanai;Mips;MSP430;NVPTX;PowerPC;Sparc;SystemZ;X86;XCore -- Configuring incomplete, errors occurred! See the thread http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20171211/509225.html for discussion of this fix. llvm-svn: 320556
* [cmake] Pass TARGETS_TO_BUILD through to host tools buildJustin Bogner2017-12-111-1/+6
| | | | | | | | | | | | | | | | | | | | In r319620, the host build was changed to use Native for TARGETS_TO_BUILD because passing semicolons through add_custom_command is surprisingly difficult. However, Native really doesn't make any sense here, and it only works because we don't technically do any codegen in the host tools so pretty well anything will "work". The problem here is that passing something other than the correct value is very fragile - as evidence note how the llvm-config in the host tools acts differently than the target one now, and misreports the targets to build. Similarly, if there is any logic conditional on the targets in tablegen (now or in the future), it will do the wrong thing. To fix this, we need to escape the semicolons in the targets string and pass it through to the child cmake invocation. llvm-svn: 320413
* [cmake] Only pass CMAKE_SYSROOT if non-emptyShoaib Meenai2017-12-081-1/+5
| | | | | | | | | | | In my build environment (cmake 3.6.1 and gcc 4.8.5 on CentOS 7), having an empty CMAKE_SYSROOT in the cache results in --sysroot="" being passed to all compile commands, and then the compiler errors out because of the empty sysroot. Only set CMAKE_SYSROOT if non-empty to avoid this. Differential Revision: https://reviews.llvm.org/D40934 llvm-svn: 320183
* [cmake] Make setting of CMAKE_C(XX)_COMPILER flags overridable for cross-buildsPavel Labath2017-12-081-5/+9
| | | | | | | | | | | | | | | | | | | | | | | Summary: r319898 made it possible to override these variables via the CROSS_TOOLCHAIN_FLAGS setting, but this only worked if one explicitly specifies these variables there. If, instead, one uses CROSS_TOOLCHAIN_FLAGS to specify a toolchain file (as our internal builds do, to point cmake to a checked-in toolchain), the CMAKE_C(XX)_COMPILER flags would still win over the ones specified by the toolchain file. To fix is to make the mere presence of these flags overridable. I do this by putting them as a default value for the CROSS_TOOLCHAIN_FLAGS setting, so they can be overridden at cmake configuration time. Reviewers: hintonda, beanz Subscribers: bogner, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D40947 llvm-svn: 320138
* [CMake] Use PRIVATE when linking LLVM fuzzers.Matt Morehouse2017-12-061-1/+1
| | | | | | More fuzzers missed by r319840. llvm-svn: 319987
* [cmake] Remove unnecessary header include in atomics checkShoaib Meenai2017-12-061-1/+0
| | | | | | | | | | | | | | | | | | | | | The header include was required to work around PR19898, as noted in that comment. That PR has since been marked resolved fixed, and the configuration check passes without the header inclusion both when compiling on Windows with cl and when cross-compiling on Linux using clang-cl. I noticed this because the inclusion was cased incorrectly (Intrin.h instead of intrin.h), which when cross-compiling on a case sensitive file system would cause the intrin.h from the Windows SDK to be included (which LLVM can't handle) instead of the one from clang's resource directory, making the check fail. This is the same issue as r309980. Correcting the case of the inclusion makes the check pass when cross compiling, but it seems better to get rid of the inclusion entirely, since it appears to be unnecessary now. Differential Revision: https://reviews.llvm.org/D40910 llvm-svn: 319917
* [cmake] Move CMAKE_(C|CXX)_COMPILER variables before CROSS_TOOLCHAIN_FLAGS soDon Hinton2017-12-061-2/+2
| | | | | | | | | | | | | | | | | | | | | they can be overridden when cross compiling. Summary: Since CROSS_TOOLCHAN_FLAGS can set CMAKE_(C|CXX)_COMPILER variables, move the compiler variables up front so they can be overridden. This is a followup to https://reviews.llvm.org/D40229 committed in rL319620. Thanks to Pavel Labath for reporting this issue. Reviewers: labath, beanz Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D40896 llvm-svn: 319898
* [CMake] Use PRIVATE in target_link_libraries for executablesShoaib Meenai2017-12-052-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840
* [cmake] Modernize some conditionals. NFCShoaib Meenai2017-12-051-2/+2
| | | | | | | | | | | | | The "x${...}" form was a workaround for CMake versions prior to 3.1, where the if command would interpret arguments as variables even when quoted [1]. We can drop the workaround now that our minimum CMake version is 3.4. [1] https://cmake.org/cmake/help/v3.1/policy/CMP0054.html Differential Revision: https://reviews.llvm.org/D40744 llvm-svn: 319723
* [CMake] Don't use comma as an alternate separatorPetr Hosek2017-12-051-2/+2
| | | | | | | | | | | Using comma can break in cases when we're passing flags that already use comma as a separator. Fixes PR35504. Differential Revision: https://reviews.llvm.org/D40761 llvm-svn: 319719
* [cmake] Re-commit: Remove redundant call to cmake when building host tools.Don Hinton2017-12-021-28/+15
| | | | | | | | | | | | | | | | | Also pass CMAKE_(C|CXX)_COMPILER to add_custom_command. Summary: Remove the redundant, config-time call to cmake when building host tools for cross compiles or optimized tablegen.. The config-time call to cmake is redundant because it will always get called again when the CONFIGURE_LLVM_${target_name} target fires at build-time. This speeds up initial configuration, but has no affect on build behavior. Differential Revision: https://reviews.llvm.org/D40229 llvm-svn: 319620
* CMAKE: help CheckAtomic find check_library_existsMartell Malone2017-12-021-0/+1
| | | | | | | | | | | | | | | | | lldb fails to build standalone on x86 -- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Failed CMake Error at CheckAtomic.cmake:66 (check_library_exists): Unknown CMake command "check_library_exists". Call Stack (most recent call first): LLDBStandalone.cmake:90 (include) CMakeLists.txt:3 (include) Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D40220 llvm-svn: 319610
* [cmake] Revert (rL319574): Resubmit Remove redundant call to cmake when ↵Don Hinton2017-12-011-13/+28
| | | | | | | | | | building host tools. Still fails for some bots. Differential Revision: https://reviews.llvm.org/D40229 llvm-svn: 319582
* [cmake] Resubmit Remove redundant call to cmake when building host tools.Don Hinton2017-12-011-28/+13
| | | | | | | | | | | | | | | | | Only pass Native to LLVM_TARGETS_TO_BUILD. Summary: Remove the redundant, config-time call to cmake when building host tools for cross compiles or optimized tablegen.. The config-time call to cmake is redundant because it will always get called again when the CONFIGURE_LLVM_${target_name} target fires at build-time. This speeds up initial configuration, but has no affect on build behavior. Differential Revision: https://reviews.llvm.org/D40229 llvm-svn: 319574
* [cmake] Expose opt-viewer availabilityAdam Nemet2017-12-011-0/+1
| | | | | | This will be used in https://github.com/apple/swift/pull/12938 llvm-svn: 319511
* [llvm] Add stripped installation targetsShoaib Meenai2017-11-303-35/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | CMake's generated installation scripts support `CMAKE_INSTALL_DO_STRIP` to enable stripping the installed binaries. LLVM's build system doesn't expose this option to the `install-` targets, but it's useful in conjunction with `install-distribution`. Add a new function to create the install targets, which creates both the regular install target and a second install target that strips during installation. Change the creation of all installation targets to use this new function. Stripping doesn't make a whole lot of sense for some installation targets (e.g. the LLVM headers), but consistency doesn't hurt. I'll make other repositories (e.g. clang, compiler-rt) use this in a follow-up, and then add an `install-distribution-stripped` target to actually accomplish the end goal of creating a stripped distribution. I don't want to do that step yet because the creation of that target would depend on the presence of the `install-*-stripped` target for each distribution component, and the distribution components from other repositories will be missing that target right now. Differential Revision: https://reviews.llvm.org/D40620 llvm-svn: 319480
* [cmake] Include project name in Sphinx doctree dir to fix race conditionsMichal Gorny2017-11-301-1/+1
| | | | | | | | | | | | | | | | Modify add_sphinx_target() to include the project name alongside builder in Sphinx doctree directory. This aims to avoid crashes due to race conditions between multiple Sphinx instances running in parallel that attempt to create or read that directory simultaneously. This problem has originally been addressed in r283188. However, that commit presumed that there will be only one target per builder being run. However, r314863 introduced a second manpage target, reintroducing the race condition. Differential Revision: https://reviews.llvm.org/D40656 llvm-svn: 319461
* [cmake] Replace -Wall with /W4 in clang-cl options now that -Wall aliases ↵Greg Bedwell2017-11-291-60/+69
| | | | | | | | | | | | | | | -Weverything Instead, reuse the code-path for cl.exe that adds /W4 , which for clang-cl aliases clang's "-Wall -Wextra" which matches what clang-cl's /Wall previously aliased. This should restore the verbosity of a Windows selfhost build back to its previous levels. Differential Revision: https://reviews.llvm.org/D40603 llvm-svn: 319330
* Rollback r319176.Don Hinton2017-11-291-13/+28
| | | | | | | The ';' separators in LLVM_TARGETS_TO_BUILD disappear when list variables are evaluated in custom commands. llvm-svn: 319268
* [cmake] Pass LLVM_USE_LINKER flag when building host tools, e.g.,Don Hinton2017-11-281-1/+4
| | | | | | | | LLVM_OPTIMIZED_TABLEGEN=ON, and not crosscompiling. Differential Revision: https://reviews.llvm.org/D39734 llvm-svn: 319228
* [cmake] Remove redundant call to cmake when building host tools.Don Hinton2017-11-281-26/+10
| | | | | | | | | | | | | | | | | | | | | Summary: Remove the redundant, config-time call to cmake when building host tools for cross compiles or optimized tablegen.. The config-time call to cmake is redundant because it will always get called again when the CONFIGURE_LLVM_${target_name} target fires at build-time. This speeds up initial configuration, but has no affect on build behavior. Reviewers: beanz Reviewed By: beanz Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D40229 llvm-svn: 319176
* [CMake] Pass LLVM_HOST_TRIPLE to external projectsPetr Hosek2017-11-271-0/+1
| | | | | | | | | LLVM runtimes rely on LLVM_HOST_TRIPLE being set in their builds and tests so make sure it's being passed down. Differential Revision: https://reviews.llvm.org/D40515 llvm-svn: 319109
* [cmake] Pass -Wl,-z,nodelete on Linux to prevent unloadingMichal Gorny2017-11-271-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Prevent unloading shared libraries on Linux when dlclose() is called. This is necessary since command-line option parsing API relies on registering the global option instances in the option parser instance which can be loaded in a different shared library. Given that we can't reliably remove those options when a library is unloaded, the parser ends up containing dangling references. Since glibc has relatively complex library unloading rules, some of the LLVM libraries can be unloaded while others (including the Support library) stay loaded causing quite a mayhem. To reliably prevent that, just forbid unloading all libraries -- it's a very bad idea anyway. While the issue arguably happens only with BUILD_SHARED_LIBS, it may affect any library reusing llvm::cl interface. Based on patch provided Ross Hayward on https://bugs.gentoo.org/617154. Previously hit by Fedora back in Feb 2016: https://lists.freedesktop.org/archives/mesa-dev/2016-February/107242.html Differential Revision: https://reviews.llvm.org/D40459 llvm-svn: 319105
* Use LIST_SEPARATOR rather than escaping in ExternalProject_AddPetr Hosek2017-11-271-1/+2
| | | | | | | | | | | Escaping ; in list arguments passed to ExternalProject_Add doesn't seem to be working in newer versions of CMake (see https://public.kitware.com/Bug/view.php?id=16137 for more details). Use a custom LIST_SEPARATOR instead which is the officially supported way. Differential Revision: https://reviews.llvm.org/D40232 llvm-svn: 319089
OpenPOWER on IntegriCloud