summaryrefslogtreecommitdiffstats
path: root/llvm/cmake/modules/AddLLVM.cmake
Commit message (Collapse)AuthorAgeFilesLines
* [CMake] Teach the build system to codesign built productsJustin Bogner2018-07-101-0/+29
| | | | | | | | | | | Automatically codesign all executables and dynamic libraries if a codesigning identity is given (via LLVM_CODESIGNING_IDENTITY). This option is darwin only for now. Also update platforms/iOS.cmake to pick up the right versions of codesign and codesign_allocate. llvm-svn: 336708
* [cmake] Change WIN32 test to CMAKE_HOST_WIN32Filipe Cabecinhas2018-06-291-1/+1
| | | | | | | | | The test is about what can be run on the host, not the cmake target. When cross-compiling (compiler-rt at least) on Windows, we end up with lit being unable to run llvm-lit because it can't find the llvm-lit module. llvm-svn: 335961
* [CMake] Respect CMAKE_STRIP and CMAKE_DSYMUTIL on apple platformsJustin Bogner2018-06-281-2/+8
| | | | | | | | This allows overriding the strip and dsymutil tools, and updates iOS.cmake to do so. I've also added libtool to iOS.cmake, but it was already respecting CMAKE_LIBTOOL if set. llvm-svn: 335900
* [CMake] Do not use --gc-sections on OpenBSDBrad Smith2018-06-231-1/+1
| | | | llvm-svn: 335425
* [cmake] Change ON/OFF to YES/NO. NFCShoaib Meenai2018-06-141-9/+9
| | | | | | compnerd pointed out that the latter reads better over here. llvm-svn: 334781
* [cmake] Add linker detection for Apple platformsShoaib Meenai2018-06-141-1/+14
| | | | | | | | | | | | | | | | LLVM currently assumes that Apple platforms will always use ld64. In the future, LLD Mach-O might also be supported, so add the beginnings of linker detection support. ld64 is currently the only detected linker, since `ld64.lld -v` doesn't yield any useful version output, but we can add that detection later, and in the meantime it's still useful to have the ld64 identification. Switch clang's order file check to use this new detection rather than just checking for the presence of an ld64 executable. Differential Revision: https://reviews.llvm.org/D48201 llvm-svn: 334780
* [CMake] Use CMAKE_OBJCOPY and CMAKE_STRIP to externalize debug infoPetr Hosek2018-05-091-3/+3
| | | | | | | | | | Don't hardcode objcopy and strip names, rather use CMAKE_OBJCOPY and CMAKE_STRIP variables which allows users to override the tools used such as using llvm-objcopy and llvm-strip instead of binutils versions. Differential Revision: https://reviews.llvm.org/D46611 llvm-svn: 331827
* [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
* 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
* [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
* [cmake] Use symlinks for Windows-hosted toolchains built on UnixShoaib Meenai2018-01-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Use PRIVATE when linking LLVM fuzzers.Matt Morehouse2017-12-061-1/+1
| | | | | | More fuzzers missed by r319840. llvm-svn: 319987
* [CMake] Use PRIVATE in target_link_libraries for executablesShoaib Meenai2017-12-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [llvm] Add stripped installation targetsShoaib Meenai2017-11-301-25/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | 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] Allow for Solaris ld -V output on stdoutMichal Gorny2017-11-171-1/+2
| | | | | | | | | | | | | | | | | | In recent versions of Solaris 11.4 (previously 12), ld -V output went to stdout instead of stderr. Since AddLLVM.cmake only expects it on stderr, Solaris ld wasn't properly detected and options not understood by it are passed during the build. The following patch fixes this, allowing for both variants. Tested on i386-pc-solaris2.11.4 (on top of D35755 which is needed for proper Solaris support). Patch by Rainer Orth. Differential Revision: https://reviews.llvm.org/D39601 llvm-svn: 318532
* Move the setting of LLVM_BUILD_MODE to a macro so that we can re-use it in ↵Greg Bedwell2017-11-131-6/+10
| | | | | | | | compiler-rt Differential Revision: https://reviews.llvm.org/D38470 llvm-svn: 318034
* [CMake] Fix linker detection in AddLLVM.cmakeTim Shen2017-10-301-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Fix linker not being correctly detected when a custom one is specified through LLVM_USE_LINKER CMake variable. In particular, cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=gold ../llvm resulted into Linker detection: GNU ld instead of Linker detection: GNU Gold due to the construction not accounting for such variable. It led to the general confusion and prevented setting linker-specific flags inside functions defined in AddLLVM.cmake. Thanks Oleksii Vilchanskyi for the patch! llvm-svn: 316956
* Force #define GTEST_LANG_CXX11.Zachary Turner2017-10-271-0/+7
| | | | | | | | | | | | | | | | | | gtest depends on this #define to determine whether it can use various classes like std::tuple, or whether it has to fall back to experimental classes in the std::tr1 namespace. The check in the current version of gtest relies on the value of the `__cplusplus` macro, but MSVC provides a non-conformant value of this macro, making it effectively impossible to detect C++11. In short, LLVM compiled with MSVC has been silently using the tr1 versions of several classes since the beginning of time. This would normally be pretty benign, except that in the latest preview of MSVC they have marked all of the tr1 classes deprecated, so it spews thousands of warnings. llvm-svn: 316798
* [cmake] Restrict resource file usage to Windows build hostsShoaib Meenai2017-10-251-2/+2
| | | | | | | | | | | | | | | | Resource file compilation requires a working resource compiler. Unfortunately, llvm-rc isn't quite there yet [1], and cmake's rc invocation only works on Windows [2]. Until both those issues are addressed, disable resource file usage on non-Windows build hosts, to unblock Windows cross-compilation. This is also consistent with the existing comment, which says "If *on Windows* and building with MSVC". [1] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118433.html [2] https://public.kitware.com/pipermail/cmake/2017-October/066441.html Differential Revision: https://reviews.llvm.org/D39265 llvm-svn: 316594
* [cmake] Allow building fuzzers with OSS-Fuzz flags.Matt Morehouse2017-10-121-2/+7
| | | | | | | | | | | | Reviewers: kcc, bogner Reviewed By: bogner Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D38858 llvm-svn: 315629
* Revert "[CMake] Remove `CMAKE_.*_OUTPUT_DIRECTORY` (NFCI)"Brian Gesiak2017-09-291-0/+2
| | | | | | | | Summary: It appears polly makes use of the `CMAKE_RUNTIME_OUTPUT_DIRECTORY` variable when configuring its lit test suite. Reverting this for now. llvm-svn: 314551
* [CMake] Remove `CMAKE_.*_OUTPUT_DIRECTORY` (NFCI)Brian Gesiak2017-09-291-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Three `CMAKE_.*_OUTPUT_DIRECTORY` variables used to be set in CMake and referenced in various other parts of the project. However, in r198205 chapuni added a note to "don't set them anymore", and any remaining references to them were subsequently removed in r198316 and r199592. Now that the variables are no longer used anywhere, remove them, along with the comments advising against using them any longer. Test Plan: I ran `check-all` and confirmed the tests built and passed. Reviewers: beanz, chapuni Reviewed By: beanz Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D38389 llvm-svn: 314550
* [lit] Add a test for the builtin config map.Zachary Turner2017-09-211-3/+6
| | | | | | | | | | | | | | | | | | | Config map is not exposed through the command line, so testing this is somewhat tricky. But basically we need a test that if a custom driver builds a config map and passes it to main, it gets respected. A config map allows config files in the source tree to be mapped to alternate config files in the build tree. This particular test works by having two config files in separate directories, and setting up a config map to have that redirects A/lit.site.cfg to B/altconfig. Then, we print a message in A/lit.site.cfg and B/altconfig and check that we do see the output from B but don't see the output from A. Additionally we test that the test suite specified by A's config map is properly discovered. Differential Revision: https://reviews.llvm.org/D38105 llvm-svn: 313887
* [lit] Make lit support config files with .py extension.Zachary Turner2017-09-211-6/+12
| | | | | | | | | | | | | | | | | Many editors and Python-related diagnostics tools such as debuggers break or fail in mysterious ways when python files don't end in .py. This is especially true on Windows, but still exists on other platforms. I don't want to be too heavy handed in changing everything across the board, but I do want to at least *allow* lit configs to have .py extensions. This patch makes the discovery process first look for a config file with a .py extension, and if one is not found, then looks for a config file using the old method. So for existing users, there should be no functional change. Differential Revision: https://reviews.llvm.org/D37838 llvm-svn: 313849
* Make libcxx tests work when llvm sources are not present.Zachary Turner2017-09-201-3/+6
| | | | | | | | | | | | | | | | | | | Despite a strong CMake warning that this is an unsupported libcxx build configuration, some bots still rely on being able to check out lit and libcxx independently with no LLVM sources, and then run lit against libcxx. A previous patch broke that workflow, so this is making it work again. Unfortunately, it breaks generation of the llvm-lit script for libcxx, but we will just have to live with that until a solution is found that allows libcxx to make more use of llvm build pieces. libcxx can still run tests by using the ninja check target, or by running lit.py directly against the build tree or source tree. Differential Revision: https://reviews.llvm.org/D38057 llvm-svn: 313763
* Resubmit "Fix llvm-lit script generation in libcxx."Zachary Turner2017-09-191-3/+3
| | | | | | | | After speaking with the libcxx owners, they agreed that this is a bug in the bot that needs to be fixed by the bot owners, and the CMake changes are correct. llvm-svn: 313643
* Revert "Fix llvm-lit script generation in libcxx."Zachary Turner2017-09-191-3/+3
| | | | | | | | | | | | This reverts commit 4ad71811d45268d81b60f27e3b8b2bcbc23bd7b9. There is a bot that is checking out libcxx and lit with nothing else and then running lit.py against the test tree. Since there's no LLVM source tree, there's no LLVM CMake. CMake actually reports this as a warning saying unsupported libcxx configuration, but I guess someone is depending on it anyway. llvm-svn: 313607
* Fix llvm-lit script generation in libcxx.Zachary Turner2017-09-191-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D37997 llvm-svn: 313606
* [cmake] Add a simple function to dump all variables.Zachary Turner2017-09-181-0/+7
| | | | | | This is useful when debugging CMake problems. llvm-svn: 313574
* Resubmit "Add a shared llvm.lit module that all test suites can use."Zachary Turner2017-09-161-0/+4
| | | | | | | | There were some issues surrounding Py2 / Py3 compatibility, but I've now tested with both Py2 and Py3 and everything seems to work. llvm-svn: 313467
* Revert lit changes related to lit.llvm module.Zachary Turner2017-09-161-4/+0
| | | | | | | | It looks like this is going to be non-trivial to get working in both Py2 and Py3, so for now I'm reverting until I have time to fully test it under Python 3. llvm-svn: 313429
* Resubmit "[lit] Add a lit.llvm module that all llvm projects can use"Zachary Turner2017-09-161-0/+4
| | | | | | | This was reverted alongside the revert of the lit/llvm-lit refactor, but now that that has re-landed, I'm relanding this as well. llvm-svn: 313426
* Resubmit "[lit] Force site configs to run before source-tree configs"Zachary Turner2017-09-151-8/+66
| | | | | | | | | | | | | | | | | | | | This is a resubmission of r313270. It broke standalone builds of compiler-rt because we were not correctly generating the llvm-lit script in the standalone build directory. The fixes incorporated here attempt to find llvm/utils/llvm-lit from the source tree returned by llvm-config. If present, it will generate llvm-lit into the output directory. Regardless, the user can specify -DLLVM_EXTERNAL_LIT to point to a specific lit.py on their file system. This supports the use case of someone installing lit via a package manager. If it cannot find a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or invalid, then we print a warning that tests will not be able to run. Differential Revision: https://reviews.llvm.org/D37756 llvm-svn: 313407
* Revert "[lit] Force site configs to run before source-tree configs"Zachary Turner2017-09-151-17/+5
| | | | | | | | This patch is still breaking several multi-stage compiler-rt bots. I already know what the fix is, but I want to get the bots green for now and then try re-applying in the morning. llvm-svn: 313335
* [cmake] Fix a variable shadowing bugReid Kleckner2017-09-151-0/+1
| | | | llvm-svn: 313331
* [lit] Revert "Add a lit.llvm module that all llvm projects can use"Zachary Turner2017-09-151-4/+0
| | | | | | | This is breaking due to some changes I forgot to merge in, so I'm temporarily reverting them until I can re-test that this works. llvm-svn: 313328
* [lit] Add a lit.llvm module that all test suites can use.Zachary Turner2017-09-151-0/+4
| | | | | | | | | | | | | | To further reduce duplicate code, this patch introduces a module that configs can simply import and get access to a lot of useful functionality such as setting up paths, adding features that are useful across all projects, and other utility-type functions. For now this only updates llvm's suite to use this new library, but subsequent patches will update other projects. Differential Revision: https://reviews.llvm.org/D37778 llvm-svn: 313325
* [lit] Force site configs to be run before source-tree configsZachary Turner2017-09-141-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch simplifies LLVM's lit infrastructure by enforcing an ordering that a site config is always run before a source-tree config. A significant amount of the complexity from lit config files arises from the fact that inside of a source-tree config file, we don't yet know if the site config has been run. However it is *always* required to run a site config first, because it passes various variables down through CMake that the main config depends on. As a result, every config file has to do a bunch of magic to try to reverse-engineer the location of the site config file if they detect (heuristically) that the site config file has not yet been run. This patch solves the problem by emitting a mapping from source tree config file to binary tree site config file in llvm-lit.py. Then, during discovery when we find a config file, we check to see if we have a target mapping for it, and if so we use that instead. This mechanism is generic enough that it does not affect external users of lit. They will just not have a config mapping defined, and everything will work as normal. On the other hand, for us it allows us to make many simplifications: * We are guaranteed that a site config will be executed first * Inside of a main config, we no longer have to assume that attributes might not be present and use getattr everywhere. * We no longer have to pass parameters such as --param llvm_site_config=<path> on the command line. * It is future-proof, meaning you don't have to edit llvm-lit.in to add support for new projects. * All of the duplicated logic of trying various fallback mechanisms of finding a site config from the main config are now gone. One potentially noteworthy thing that was required to implement this change is that whereas the ninja check targets previously used the first method to spawn lit, they now use the second. In particular, you can no longer run lit.py against the source tree while specifying the various `foo_site_config=<path>` parameters. Instead, you need to run llvm-lit.py. Differential Revision: https://reviews.llvm.org/D37756 llvm-svn: 313270
* Revert "Determine up front which projects are enabled."Zachary Turner2017-09-131-33/+2
| | | | | | | | | | | This was intended to be a generic CMake solution to a problem shared across several projects. It turns out it doesn't interact very well certain CMake configurations, and furthermore the "problem" is actually not a problem, as the problematic code is never executed to begin with. So this really isn't solving anything. llvm-svn: 313191
* Determine up front which projects are enabled.Zachary Turner2017-09-121-2/+33
| | | | | | | | | | | | | | | | | | | Some projects need to add conditional dependencies on other projects. compiler-rt is already doing this, and I attempted to add this to debuginfo-tests when I ran into the ordering problem, that you can't conditionally add a dependency unless that dependency's CMakeLists.txt has already been run (which would allow you to say if (TARGET foo). The solution to this seems to be to determine very early on the entire set of projects which is enabled. This is complicated by the fact that there are multiple ways to enable projects, and different tree layouts (e.g. mono-repo, out of -tree, external, etc). This patch attempts to centralize all of this into one place, and then updates compiler-rt to demonstrate as a proof of concept how this can simplify code. Differential Revision: https://reviews.llvm.org/D37637 llvm-svn: 313091
* Move some CLI utils out of llvm-isel-fuzzer and into the libraryJustin Bogner2017-09-021-0/+1
| | | | | | | | FuzzMutate might not be the best place for these, but it makes more sense than an entirely new library for now. This will make setting up fuzz targets with consistent CLI handling easier. llvm-svn: 312425
* [CMAKE] Move version control macros to AddLLVM.cmake so they can be reused ↵Don Hinton2017-09-021-0/+33
| | | | | | | | | | | | | by clang, etc. Summary: Move version control macros, find_first_existing_file and find_first_existing_vc_file to AddLLVM.cmake so they can be reused by sub projects like clang. Differential Revision: https://reviews.llvm.org/D36971 llvm-svn: 312419
* llvm-isel-fuzzer: Make buildable and testable without libFuzzerJustin Bogner2017-09-011-2/+6
| | | | | | | | | | | | | | This adds a dummy main so we can build and run the llvm-isel-fuzzer functionality when we aren't building LLVM with coverage. The approach here should serve as a template to stop in-tree fuzzers from bitrotting (See llvm.org/pr34314). Note that I'll probably move most of the logic in DummyISelFuzzer's `main` to a library so it's easy to reuse it in other fuzz targets, but I'm planning on doing that in a follow up that also consolidates argument handling in our LLVMFuzzerInitialize implementations. llvm-svn: 312338
* cmake: Invent add_llvm_fuzzer to set up fuzzer targetsJustin Bogner2017-08-311-0/+7
| | | | | | | | | | | | | | | | This moves the cmake configuration for fuzzers in LLVM to a new macro, add_llvm_fuzzer. This will make it easier to keep things consistent while implementing llvm.org/pr34314. I've also made a couple of minor functional changes here: - the fuzzers now use add_llvm_executable rather than add_llvm_tool. This means they won't create install targets and stuff like that, because those made little sense for these fuzzers. - I've grouped these under "Fuzzers" rather than in with "Tools" for people who build with IDEs. llvm-svn: 312200
* [Solaris] Detect Solaris LD, use detection results to pass Solaris-ld optionsRui Ueyama2017-07-121-2/+17
| | | | | | | | | | | | Solaris ld is not the only linker available on Solaris. Introducing linker detection and using LLVM_LINKER_IS_SOLARISLD to select Solaris-ld specific handling. Patch by: Fedor Sergeev Differential Revision: https://reviews.llvm.org/D35325 llvm-svn: 307852
* [cmake] Remove obsolete unset in CMake.George Karpenkov2017-07-101-5/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D35024 llvm-svn: 307569
* CMake: Add LLVM_UTILS_INSTALL_DIR optionTom Stellard2017-07-051-1/+1
| | | | | | | | | | | | | | | | | | Summary: This is like the LLVM_TOOLS_INSTALL_DIR option, but for the utils that are installed when the LLVM_INSTALL_UTILS. This option defaults to 'bin' to remain consistent with the current behavior, but distros may want to install these to libexec/llvm. Reviewers: beanz Reviewed By: beanz Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D30655 llvm-svn: 307150
* [CMake] Introduce LLVM_TARGET_TRIPLE_ENV as an option to override ↵NAKAMURA Takumi2017-06-171-0/+13
| | | | | | | | | | | | | | | | | | | LLVM_DEFAULT_TARGET_TRIPLE at runtime. No behavior is changed if LLVM_TARGET_TRIPLE_ENV is blank or undefined. If LLVM_TARGET_TRIPLE_ENV is "TEST_TARGET_TRIPLE" and $TEST_TARGET_TRIPLE is not blank, llvm::sys::getDefaultTargetTriple() returns $TEST_TARGET_TRIPLE. Lit resets config.target_triple and config.environment[LLVM_TARGET_TRIPLE_ENV] to change the default target. Without changing LLVM_DEFAULT_TARGET_TRIPLE nor rebuilding, lit can be run; TEST_TARGET_TRIPLE=i686-pc-win32 bin/llvm-lit -sv path/to/test/ TEST_TARGET_TRIPLE=i686-pc-win32 ninja check-clang-tools Differential Revision: https://reviews.llvm.org/D33662 llvm-svn: 305632
* Add a linker script to version LLVM symbolsSylvestre Ledru2017-04-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds a very simple linker script to version the lib's symbols and thus trying to avoid crashes if an application loads two different LLVM versions (as long as they do not share data between them). Note that we deliberately *don't* make LLVM_5.0 depend on LLVM_4.0: they're incompatible and the whole point of this patch is to tell the linker that. Avoid unexpected crashes when two LLVM versions are used in the same process. Author: Rebecca N. Palmer <rebecca_palmer@zoho.com> Author: Lisandro Damían Nicanor Pérez Meyer <lisandro@debian.org> Author: Sylvestre Ledru <sylvestre@debian.org> Bug-Debian: https://bugs.debian.org/848368 Reviewers: beanz, rnk Reviewed By: rnk Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D31524 llvm-svn: 300496
OpenPOWER on IntegriCloud