summaryrefslogtreecommitdiffstats
path: root/llvm/cmake/modules/LLVMExternalProjectUtils.cmake
Commit message (Collapse)AuthorAgeFilesLines
* [llvm] Add llvm-lipo dependency to runtimesXin-Xin Wang2019-12-161-1/+4
| | | | | | | | | | | | | | Summary: Currently, llvm-lipo is not specified as a dependency, but it is needed when building Darwin-x86_64 runtimes, so I'm adding it to the dependencies lists. Reviewers: alexshap, beanz, phosek, compnerd, smeenai, mtrent, plotfi, xiaobai Reviewed By: phosek, smeenai Subscribers: smeenai, mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71429
* Append an executable suffix to the toolchain tool paths on Windows platform.Galina Kistanova2019-08-071-12/+12
| | | | | | | | | | | Append a default CMake suffix (CMAKE_EXECUTABLE_SUFFIX) for the build host to the toolchain tool path when adding a LLVM external project. The tool binary files should contain .exe suffix to run them properly on Windows platform when building the projects. Patch by Vlad Vereschaka. Differential Revision: https://reviews.llvm.org/D65824 llvm-svn: 368121
* [CMake] Provide an option to use relative paths in debug infoPetr Hosek2019-05-311-0/+2
| | | | | | | | | | | | | | | | | CMake always uses absolute file paths in the generated compiler invocation which results in absolute file paths being embedded in debug info. This is undesirable when building a toolchain e.g. on bots as the debug info may embed the bot source checkout path which is meaningless anywhere else. This change introduces the LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO which uses -fdebug-prefix-map (where supported) options to rewrite paths embedded into debug info with relative ones. Additionally, LLVM_SOURCE_PREFIX can be used to override the path to source directory with a different one. Differential Revision: https://reviews.llvm.org/D62622 llvm-svn: 362185
* build: use clang-cl for runtimes when targeting WindowsSaleem Abdulrasool2019-05-171-3/+18
| | | | | | | | When targeting Windows and building a runtime (subproject) prefer to use `clang-cl` rather than the `clang` driver. This allows us to cross-compile runtimes for the Windows environment from Linux. llvm-svn: 361072
* [cmake] Remove use of deprecated generator expression. NFCShoaib Meenai2019-03-301-1/+1
| | | | | | | Use $<CONFIG> instead of $<CONFIGURATION>, since the latter has been deprecated since CMake 3.0, and the former is entirely equivalent. llvm-svn: 357338
* [CMake] Support stripping and linking output to .build-id directoryPetr Hosek2019-03-091-2/+8
| | | | | | | | | | | | | | | | | | | | | When installing runtimes with install-runtimes-stripped, we don't want to just strip them, we also want to preserve the debugging information for potential debugging. To make it possible to later find the stripped debugging information, we want to use the .build-id layout: https://fedoraproject.org/wiki/RolandMcGrath/BuildID#Find_files_by_build_ID That is, for libfoo.so with build ID abcdef1234, the debugging information will be installed into lib/debug/.build-id/ab/cdef1234. llvm-objcopy already has support for stripping files and linking the debugging stripped output into the right location. However, CMake doesn't support customizing strip invocation for the *-stripped targets. So instead, we replace CMAKE_STRIP with a custom script that invokes llvm-objcopy with the right command line flags. Differential Revision: https://reviews.llvm.org/D59127 llvm-svn: 355765
* [CMake] Support cross-compiling with multi-stage buildsPetr Hosek2018-11-161-1/+28
| | | | | | | | | | | | | | | | | | | | When using multi-stage builds, we would like support cross-compilation. Example is 2-stage build when the first stage is compiled for host while the second stage is compiled for the target. Normally, the second stage would be also used for compiling runtimes, but that's not possible when cross-compiling, so we use the first stage compiler instead. However, we still want to use the second stage paths. To do so, we set the -resource-dir of the first stage compiler to point to the resource directory of the second stage. We also need compiler tools that support the target architecture. These tools are not guaranteed to be present on the host, but in case of multi-stage build, we can build these tools in the first stage. Differential Revision: https://reviews.llvm.org/D54461 llvm-svn: 347025
* [CMake] Pass CMAKE_INSTALL_DO_STRIP to external projectsPetr Hosek2018-07-151-1/+1
| | | | | | | | | This is necessary to make install-<target>-stripped work for external projects such as runtimes. Differential Revision: https://reviews.llvm.org/D49335 llvm-svn: 337115
* [CMake] Use variables rather than ":" delimitersPetr Hosek2018-06-271-8/+5
| | | | | | | | This is a more idiomatic CMake. Differential Revision: https://reviews.llvm.org/D37644 llvm-svn: 335703
* [CMake] Pass additional CMake tools to external projectsPetr Hosek2018-06-061-2/+22
| | | | | | | | | This is needed when the external projects try to use other tools besides just the compiler and the linker. Differential Revision: https://reviews.llvm.org/D47833 llvm-svn: 334136
* [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] Support for cross-compilation when build runtimesPetr Hosek2018-01-081-2/+12
| | | | | | | | | | | 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 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] 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] 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
* [llvm] Add stripped installation targetsShoaib Meenai2017-11-301-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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] 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
* 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
* [CMake] Passthrough CMAKE_SYSROOT to external projectsPetr Hosek2017-11-091-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317744
* Generate a compile_commands.json DB for external projects.George Karpenkov2017-07-201-0/+1
| | | | | | | | | | | compile_commands.json file is very useful both for tooling and for reproducible builds. For files generated from recursive CMake invocation this information was not previously generated. Differential Review: https://reviews.llvm.org/D35219 llvm-svn: 308698
* [CMake] Support multi-target runtimes buildPetr Hosek2017-07-111-1/+9
| | | | | | | | | | | | | | | | | | | | | This changes adds support for building runtimes for multiple different targets using LLVM runtimes directory. The implementation follow the model used already by the builtins build which already supports this option. To specify the runtimes targets to be built, use the LLVM_RUNTIME_TARGETS variable, where the valuae is the list of targets to build runtimes for. To pass a per target variable to the runtimes build, you can set RUNTIMES_<target>_<variable> where <variable> will be passed to the runtimes build for <target>. Each runtime target (except for the default one) will be installed into lib/<target> subdirectory. Build targets will be suffixed with the target name. Differential Revision: https://reviews.llvm.org/D32816 llvm-svn: 307731
* [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
* [CMake] Cleanup LLVM_OPTIMIZED_TABLEGENChris Bieneman2016-09-061-2/+6
| | | | | | | | | | This cleanup removes the need for the native support library to have its own target. That target was only needed because makefile builds were tripping over each other if two tablegen targets were building at the same time. This causes problems because the parallel make invocations through CMake can't communicate with each other. This is fixed by invoking make directly instead of through CMake which is how we handle this in External Project invocations. The other part of the cleanup is to mark the custom commands as USES_TERMINAL. This is a bit of a hack, but we need to ensure that Ninja generators don't invoke multiple tablegen targets in the same build dir in parallel, because that too would be bad. Marking as USES_TERMINAL does have some downside for Ninja because it results in decreased parallelism, but correct builds are worth the minor loss and LLVM_OPTIMZIED_TABLEGEN is such a huge win, it is worth it. llvm-svn: 280748
* [CMake] Make llvm-config implicit dependency for subprojectsChris Bieneman2016-08-181-1/+1
| | | | | | | | The subproject interface being used for runtime libraries expects that llvm-config is passed into the subproject for consumption. We currently do this for every subproject, so we should expect that all LLVM ExternalProjects depend on llvm-config for the time being. Eventually I'd like to see the sub-projects using LLVMConfig.cmake instead of the llvm-config binary, but that will take time to roll out. llvm-svn: 279155
* [CMake] Add LLVM runtimes directoryChris Bieneman2016-06-231-10/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
* [CMake] Removing fallback code for CMake versions before 3.1Chris Bieneman2016-06-091-14/+0
| | | | | | This code is dead code now. Out with the old, in with the new! llvm-svn: 272347
* [CMake] Cleanup ExternalProject usage of CMake 3.x featuresChris Bieneman2016-06-091-19/+7
| | | | | | All the ExternalProject features in use here are supported by CMake 3.4.3, so we don't need these version checks anymore. llvm-svn: 272327
* [CMake] Cleanup uses of USES_TERMINALChris Bieneman2016-06-081-7/+3
| | | | | | Now that we are on CMake 3.4.3 we no longer need a version check around this. llvm-svn: 272211
* [CMake] Make llvm_ExternalProject always call the build actionChris Bieneman2016-04-081-9/+17
| | | | | | | | This makes it so that when running 'ninja test-suite' from the top-level LLVM ninja build it *always* re-runs the ninja command in the test-suite directory. This mechanism is required because the top-level ninja file doesn't have a view into the subdirectory dependency tree, so it can't know what, if anything, needs to be rebuilt. llvm-svn: 265863
* [CMake] Removing an unnecessary layer of variable indirectionChris Bieneman2015-12-031-1/+1
| | | | | | This prevents passthrough variables from having values. llvm-svn: 254641
* NFC. Fixing my consistently incorrect spelling.Chris Bieneman2015-11-231-4/+4
| | | | llvm-svn: 253936
* [CMake] Fix handling of passing through semi-colon separated lists.Chris Bieneman2015-11-201-1/+2
| | | | | | When passing around CMake arguments as lists of arguments any arguments containing lists need to have their semi-colons escaped otherwise CMake will split the arguments in the middle. llvm-svn: 253719
* [CMake] Fixing passthrough for variables starting with the sub-project nameChris Bieneman2015-11-111-1/+1
| | | | | | This allows TEST_SUITE variables to be passed from the top-level CMake into the external project. llvm-svn: 252810
* [CMake] Add support for building the llvm test-suite as part of an LLVM ↵Chris Bieneman2015-11-111-0/+194
build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
OpenPOWER on IntegriCloud