summaryrefslogtreecommitdiffstats
path: root/llvm/cmake
Commit message (Collapse)AuthorAgeFilesLines
...
* Assume existence of inttypes.h and stdint.h in DataTypes.h.Nico Weber2018-04-021-34/+0
| | | | | | | | | | | | | These should exist in all toolchains LLVM supports nowadays. Enables making DataTypes.h a regular header instead of a .h.cmake file and allows deleting a bunch of cmake goop (which should also speed up cmake configure time a bit). All the code this removes is 9+ years old. https://reviews.llvm.org/D45155 llvm-svn: 328970
* Remove a few unreferenced config.h defines.Nico Weber2018-04-021-5/+0
| | | | | | | | | | | | Found by looking through the output of for f in $(grep -o '\bHAVE_[A-Z0-9_]*\b' llvm/cmake/config-ix.cmake); do echo $f $(git grep $f '*' | wc -l); done in the monorepo. llvm-svn: 328957
* 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
* Build system changes for RISCVAzharuddin Mohammed2018-03-131-0/+4
| | | | | | | | | | | | | | Summary: Build system changes for RISCV. Makes it possible to build just the RISCV target alone. Reviewers: asb, apazos, mgrang, beanz Reviewed By: asb Subscribers: mgorny, kito-cheng, shiva0217, llvm-commits Differential Revision: https://reviews.llvm.org/D44153 llvm-svn: 327423
* [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
* [opt-viewer] Check for pygments.lexer.c_cppJonas Hahnfeld2018-01-021-2/+6
| | | | | | | | | Some systems still don't have this module which was introduced in version 2.0 (CentOS 7, sigh). Differential Revision: https://reviews.llvm.org/D41611 llvm-svn: 321659
* [cmake] Always respect existing CMAKE_REQUIRED_FLAGS when adding additional ↵Don Hinton2017-12-253-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Fix clang-cl cross-compilation on macOSShoaib Meenai2017-12-152-0/+12
| | | | | | | | | | | | | | macOS paths usually start with /Users, which clang-cl interprets as a macro undefine, leading to pretty much everything failing to compile. CMake should be taught to put a -- in its compilation rules for clang-cl (and I've been meaning to submit that upstream for a while). In the meantime, however, and to support older CMake versions, we can just create a custom make rules override to fix the compilation rules. Differential Revision: https://reviews.llvm.org/D41219 llvm-svn: 320785
* [cmake] Only attempt to install MSVC system libraries on WindowsShoaib Meenai2017-12-141-7/+0
| | | | | | | | | | | | | | | | | Newer versions of CMake (I'm on 3.10, but I believe 3.9 behaves the same way) attempt to query the system for information about the VS 2017 install. Unfortunately, this query fails on non-Windows systems: cmake_host_system_information does not recognize <key> VS_15_DIR CMake isn't going to find these system libraries on non-Windows anyway (and we were previously silencing the resultant warnings in our cross-compilation toolchain), so it makes sense to just omit the attempted installation entirely on non-Windows. Differential Revision: https://reviews.llvm.org/D41220 llvm-svn: 320724
* [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] Add support for case-sensitive Windows SDKsShoaib Meenai2017-12-131-12/+77
| | | | | | | | | | When the Windows SDK is hosted on a case-sensitive filesystem (e.g. when compiling on Linux and not using ciopfs), we can automatically generate a VFS overlay for headers and symlinks for libraries. Differential Revision: https://reviews.llvm.org/D41156 llvm-svn: 320657
* [cmake] Support host architectures other than x64Shoaib Meenai2017-12-131-5/+28
| | | | | | | | Allow building for other architectures when cross-compiling for Windows. Differential Revision: https://reviews.llvm.org/D41158 llvm-svn: 320656
* [cmake] Explicitly set VS 2017 compatibilityShoaib Meenai2017-12-131-0/+1
| | | | | | | | | | | | | When cross-compiling using clang-cl 5.0 (which is currently the latest stable release of the compiler), the default MS compatibility level is set to VS 2013, which is too low to build LLVM. Explicitly set the compatibility level to VS 2017 to support cross-compiling LLVM for Windows using clang-cl 5.0. This will be a no-op when using clang-cl 6.0 and above, where the default MS compatibility level is already VS 2017. Differential Revision: https://reviews.llvm.org/D41157 llvm-svn: 320616
* [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
* Re-commit "[cmake] Enable zlib support on windows"Pavel Labath2017-12-051-33/+43
| | | | | | | | | | | | | | | | | | | | | | | | This recommits r319533 which was broken llvm-config --system-libs output. The reason was that I used find_libraries for searching for the z library. This returns absolute paths, and when these paths made it into llvm-config, it made it produce nonsensical flags. To fix this, I hand-roll a search for the library in the same way that we search for the terminfo library a couple of lines below. This is a bit less flexible than the find_library option, as it does not allow the user to specify the path to the library at configure time (which is important on windows, as zlib is unlikely to be found in any of the standard places cmake searches), but I was able to guide the build to find it with appropriate values of LIB and INCLUDE environment variables. Reviewers: compnerd, rnk, beanz, rafael Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D40779 llvm-svn: 319751
* [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
* Revert "[cmake] Enable zlib support on windows"Pavel Labath2017-12-041-39/+35
| | | | | | | | | | | | This reverts commit r319533 as it broke llvm-config --system-libs output and everything that depends on it (which is mostly out of tree or downstream folks, but includes a couple of llvm buildbots as well). I think I have a fix for this in D40779, but I want someone to look review it first. In the mean time, I am reverting this change, as it seems to break a lot of people. llvm-svn: 319663
* [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] Enable zlib support on windowsPavel Labath2017-12-011-35/+39
| | | | | | | | | | | | | | | | | | | | | | | Summary: zlib support was hard-wired to off for (non-cygwin) windows targets. This disables some features, such as reading debug info from compressed dwarf sections. This has been this way since zlib support was added in 2013 (r180083), but there is no obvious reason for that. Zlib is perfectly capable of being compiled for windows (it even has a cmake file that works out of the box). This enables one to turn on zlib support on windows, if one has zlib avaliable. Reviewers: rnk, beanz Subscribers: mgorny, aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D40655 llvm-svn: 319533
* [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
* Add opt-viewer testingAdam Nemet2017-11-291-0/+31
| | | | | | | | | | | | | | | | | | | | Detects whether we have the Python modules (pygments, yaml) required by opt-viewer and hooks this up to REQUIRES. This fixes https://bugs.llvm.org/show_bug.cgi?id=34129 (the lack of opt-viewer testing). It's also related to https://github.com/apple/swift/pull/12938 and the idea is to expose LLVM_HAVE_OPT_VIEWER_MODULES to the Swift cmake. Differential Revision: https://reviews.llvm.org/D40202 Fixes since the first commit: 1. Disable syntax highlighting as different versions of pygments generate different HTML 2. Use llvm-cxxfilt from the build llvm-svn: 319324
OpenPOWER on IntegriCloud