RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 19:23:23 +01:00
Code Issues Projects Releases Wiki Activity
26020de8d8
llvm-mirror/tools/CMakeLists.txt

55 lines
1.7 KiB
CMake
Raw Normal View History

[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working. Re-landing r242059 which re-landed r241621... I'm really bad at this. Summary (r242059): This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*. Summary (r241621): The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are: * factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools * removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off * Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code. * Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt Differential Revision: http://reviews.llvm.org/D10665 llvm-svn: 242705
2015-07-20 22:36:06 +02:00
# This file will recurse into all subdirectories that contain CMakeLists.txt
# Setting variables that match the pattern LLVM_TOOL_{NAME}_BUILD to Off will
# prevent traversing into a directory.
#
# The only tools that need to be explicitly added are ones that have explicit
# ordering requirements.
# Iterates all the subdirectories to create CMake options to enable/disable
# traversing each directory.
create_llvm_tool_options()
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 01:59:48 +02:00
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 17:54:50 +02:00
if(NOT LLVM_BUILD_LLVM_DYLIB AND NOT LLVM_BUILD_LLVM_C_DYLIB)
[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working. Re-landing r242059 which re-landed r241621... I'm really bad at this. Summary (r242059): This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*. Summary (r241621): The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are: * factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools * removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off * Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code. * Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt Differential Revision: http://reviews.llvm.org/D10665 llvm-svn: 242705
2015-07-20 22:36:06 +02:00
set(LLVM_TOOL_LLVM_SHLIB_BUILD Off)
[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working. Summary: This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*. Original Summary: The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are: * factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools * removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off * Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code. * Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt Differential Revision: http://reviews.llvm.org/D10665 llvm-svn: 242059
2015-07-13 22:23:15 +02:00
endif()
Revert r241621, "[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working." It broke the build that relies on LLVM_EXTERNAL_CLANG_*. llvm-svn: 241663
2015-07-08 04:35:43 +02:00
[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working. Re-landing r242059 which re-landed r241621... I'm really bad at this. Summary (r242059): This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*. Summary (r241621): The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are: * factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools * removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off * Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code. * Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt Differential Revision: http://reviews.llvm.org/D10665 llvm-svn: 242705
2015-07-20 22:36:06 +02:00
if(NOT LLVM_USE_INTEL_JITEVENTS )
set(LLVM_TOOL_LLVM_JITLISTENER_BUILD Off)
endif()
Revert "[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working." Reverting r242059 because it broke some bots. I'm attempting to reproduce the failures now. llvm-svn: 242060
2015-07-13 22:30:58 +02:00
[CMake] don't build libLTO when LLVM_ENABLE_PIC is OFF When cmake is run with -DLLVM_ENABLE_PIC=OFF, build fails while linking shared library libLTO.so, because its dependencies are built with -fno-PIC. More details here: https://llvm.org/bugs/show_bug.cgi?id=26484. This diff reverts r252652 (git 9fd4377ddb83aee3c049dc8757e7771edbb8ee71), which removed check NOT LLVM_ENABLE_PIC before disabling build for libLTO.so. Patch by Igor Sugak! Differential Revision: http://reviews.llvm.org/D17049 llvm-svn: 260703
2016-02-12 20:02:39 +01:00
if(CYGWIN OR NOT LLVM_ENABLE_PIC)
[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working. Re-landing r242059 which re-landed r241621... I'm really bad at this. Summary (r242059): This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*. Summary (r241621): The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are: * factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools * removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off * Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code. * Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt Differential Revision: http://reviews.llvm.org/D10665 llvm-svn: 242705
2015-07-20 22:36:06 +02:00
set(LLVM_TOOL_LTO_BUILD Off)
endif()
Revert "[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working." Reverting r242059 because it broke some bots. I'm attempting to reproduce the failures now. llvm-svn: 242060
2015-07-13 22:30:58 +02:00
[CMake] Adding llvm-profdata to the list of tools clang needs. Bootstrapping clang to generate PGO data (patches coming soon), requires llvm-profdata targets to be generated before clang. llvm-svn: 255794
2015-12-16 19:30:36 +01:00
# Add LTO, llvm-ar, llvm-config, and llvm-profdata before clang, ExternalProject
# requires targets specified in DEPENDS to exist before the call to
# ExternalProject_Add.
[CMake] Add lto subdirectory explicitly. This is required because ExternalProject_Add requires all targets specified in the DEPENDS argument must exist before calling ExternalProject_Add. I have a follow-up patch to clang that enables using the just-built libLTO in bootstrap builds, so we need to be able to add the LTO target as a dependency in clang. llvm-svn: 247316
2015-09-10 20:22:33 +02:00
add_llvm_tool_subdirectory(lto)
[CMake] Add the gold plugin before clang This is needed to connect dependencies between the LLVMgold plugin and the clang stage-2 builds due to limitations in ExternalProject_Add. Patch by Mike Edwards Differential Revision: http://reviews.llvm.org/D17655 llvm-svn: 262067
2016-02-26 22:07:04 +01:00
add_llvm_tool_subdirectory(gold)
[CMake] Add llvm-ar subdirectory explicitly. This is required because ExternalProject_Add requires all targets specified in the DEPENDS argument must exist before calling ExternalProject_Add. llvm-svn: 247592
2015-09-14 20:36:40 +02:00
add_llvm_tool_subdirectory(llvm-ar)
[CMake] We need to explicitly add llvm-config before clang so that LLVM_BUILD_EXTERNAL_COMPILER_RT can depend on llvm-config. This patch is a required stepping stone to fix PR14109. llvm-svn: 249202
2015-10-03 00:28:48 +02:00
add_llvm_tool_subdirectory(llvm-config)
Fixup r271533, or check-clang didn't find llvm-lto as the target. llvm-svn: 271585
2016-06-02 22:39:24 +02:00
add_llvm_tool_subdirectory(llvm-lto)
[CMake] Adding llvm-profdata to the list of tools clang needs. Bootstrapping clang to generate PGO data (patches coming soon), requires llvm-profdata targets to be generated before clang. llvm-svn: 255794
2015-12-16 19:30:36 +01:00
add_llvm_tool_subdirectory(llvm-profdata)
[CMake] Add lto subdirectory explicitly. This is required because ExternalProject_Add requires all targets specified in the DEPENDS argument must exist before calling ExternalProject_Add. I have a follow-up patch to clang that enables using the just-built libLTO in bootstrap builds, so we need to be able to add the LTO target as a dependency in clang. llvm-svn: 247316
2015-09-10 20:22:33 +02:00
[CMake] Projects supported via LLVM_EXTERNAL_*_SOURCE_DIR need to be explicitly specified. One part of my refactoring from r242705 is untenable due to how CMake caches variables. There is no way other than caching to allow variables to be set in one directory and globally readable, but we really don't want to cache the temporary value marking that a directory has already been included. llvm-svn: 242793
2015-07-21 17:53:09 +02:00
# Projects supported via LLVM_EXTERNAL_*_SOURCE_DIR need to be explicitly
# specified.
add_llvm_external_project(clang)
add_llvm_external_project(lld)
add_llvm_external_project(lldb)
Add `mlir` to -DLLVM_ALL_PROJECTS CMake option
2019-12-24 08:23:51 +01:00
add_llvm_external_project(mlir)
[Flang] add flang as a new subproject in cmake Summary: This patch is some minor prep work for merging the flang(f18) project into the monorepo. This patch adds "flang" as a supported target for the LLVM_ENABLE_PROJECTS option. Reviewers: fhahn, tstellar, jdoerfert, beanz, DavidTruby Reviewed By: DavidTruby Subscribers: hfinkel, DavidTruby, aartbik, mgorny, llvm-commits Tags: #flang, #llvm Differential Revision: https://reviews.llvm.org/D72416
2020-04-09 17:13:11 +02:00
# Flang depends on mlir, so place it afterward
add_llvm_external_project(flang)
[CMake] Projects supported via LLVM_EXTERNAL_*_SOURCE_DIR need to be explicitly specified. One part of my refactoring from r242705 is untenable due to how CMake caches variables. There is no way other than caching to allow variables to be set in one directory and globally readable, but we really don't want to cache the temporary value marking that a directory has already been included. llvm-svn: 242793
2015-07-21 17:53:09 +02:00
[CMake] Treating LLVM_INCLUDE_TOOLS, which is a bool, as a string to change behaviors of the build is a dirty hack. We shouldn't do it. Summary: I don't think anyone is relying on this behavior for bootstrapping (because I don't think it works), but if you do need it, speak now or forever hold your peace. Reviewers: chapuni, samsonov Reviewed By: samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10613 llvm-svn: 240344
2015-06-22 23:58:02 +02:00
# Automatically add remaining sub-directories containing a 'CMakeLists.txt'
# file as external projects.
[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working. Re-landing r242059 which re-landed r241621... I'm really bad at this. Summary (r242059): This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*. Summary (r241621): The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are: * factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools * removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off * Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code. * Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt Differential Revision: http://reviews.llvm.org/D10665 llvm-svn: 242705
2015-07-20 22:36:06 +02:00
add_llvm_implicit_projects()
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 01:59:48 +02:00
Generalize the pass registration mechanism used by Polly to any third-party tool There's quite a lot of references to Polly in the LLVM CMake codebase. However the registration pattern used by Polly could be useful to other external projects: thanks to that mechanism it would be possible to develop LLVM extension without touching the LLVM code base. This patch has two effects: 1. Remove all code specific to Polly in the llvm/clang codebase, replaicing it with a generic mechanism 2. Provide a generic mechanism to register compiler extensions. A compiler extension is similar to a pass plugin, with the notable difference that the compiler extension can be configured to be built dynamically (like plugins) or statically (like regular passes). As a result, people willing to add extra passes to clang/opt can do it using a separate code repo, but still have their pass be linked in clang/opt as built-in passes. Differential Revision: https://reviews.llvm.org/D61446
2019-06-08 17:37:47 +02:00
add_llvm_external_project(polly)
Add new LLVM_EXTERNAL_PROJECTS option to cmake The new option makes it possible to build external projects as part of the llvm build without copying (or symlinking) then into llvm/tool with specifying a few additional cmake variables. Example usage (2 additional project called foo and bar): -DLLVM_EXTERNAL_PROJECTS="Foo;Bar" -DLLVM_EXTERNAL_FOO_SOURCE_DIR=/src/foo -DLLVM_EXTERNAL_BAR_SOURCE_DIR=/src/bar Note: This is the extension of the approach we already support for clang/lldb/poly with adding an option to specify additional supported projects. Differential revision: http://reviews.llvm.org/D20838 llvm-svn: 271440
2016-06-02 01:00:45 +02:00
# Add subprojects specified using LLVM_EXTERNAL_PROJECTS
foreach(p ${LLVM_EXTERNAL_PROJECTS})
add_llvm_external_project(${p})
endforeach(p)
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 01:59:48 +02:00
set(LLVM_COMMON_DEPENDS ${LLVM_COMMON_DEPENDS} PARENT_SCOPE)
Reference in New Issue Copy Permalink