maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

62 lines
1.8 KiB
CMake
Raw Normal View History

llvmbuildectomy - replace llvm-build by plain cmake No longer rely on an external tool to build the llvm component layout. Instead, leverage the existing `add_llvm_componentlibrary` cmake function and introduce `add_llvm_component_group` to accurately describe component behavior. These function store extra properties in the created targets. These properties are processed once all components are defined to resolve library dependencies and produce the header expected by llvm-config. Differential Revision: https://reviews.llvm.org/D90848
2020-10-10 00:41:21 +08:00
include(LLVM-Build)
Try to fix a circular dependency in the modules build. llvm-svn: 280746
2016-09-07 04:16:19 +08:00
# `Demangle', `Support' and `TableGen' libraries are added on the top-level
# CMakeLists.txt
Move library stuff out of the toplevel CMakeLists.txt file. llvm-svn: 125968
2011-02-19 06:06:14 +08:00
Rename VMCore directory to IR. Aside from moving the actual files, this patch only updates the build system and the source file comments under lib/... that are relevant. I'll be updating other docs and other files in smaller subsequnet commits. While I've tried to test this, but it is entirely possible that there will still be some build system fallout. Also, note that I've not changed the library name itself: libLLVMCore.a is still the library name. I'd be interested in others' opinions about whether we should rename this as well (I think we should, just not sure what it might break) llvm-svn: 171359
2013-01-02 17:10:48 +08:00
add_subdirectory(IR)
Re-apply "Introduce FuzzMutate library" Same as r311392 with some fixes for library dependencies. Thanks to Chapuni for helping work those out! Original commit message: This introduces the FuzzMutate library, which provides structured fuzzing for LLVM IR, as described in my EuroLLVM 2017 talk. Most of the basic mutators to inject and delete IR are provided, with support for most basic operations. llvm-svn: 311402
2017-08-22 06:57:06 +08:00
add_subdirectory(FuzzMutate)
Reland [FileCheck] Move FileCheck implementation out of LLVMSupport into its own library This relands e9a3d1a401b07cbf7b11695637f1b549782a26cd which was originally missing linking LLVMSupport into LLMVFileCheck which broke the SHARED_LIBS build. Original summary: The actual FileCheck logic seems to be implemented in LLVMSupport. I don't see a good reason for having FileCheck implemented there as it has a very specific use while LLVMSupport is a dependency of pretty much every LLVM tool there is. In fact, the only use of FileCheck I could find (outside the FileCheck tool and the FileCheck unit test) is a single call in GISelMITest.h. This moves the FileCheck logic to its own LLVMFileCheck library. This way only FileCheck and the GlobalISelTests now have a dependency on this code. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D86344
2020-09-01 19:21:18 +08:00
add_subdirectory(FileCheck)
[elfabi] Move llvm-elfabi related code to InterfaceStub library This change moves elfabi related code to llvm/InterfaceStub library so it can be shared by multiple llvm tools without causing cyclic dependencies. Differential Revision: https://reviews.llvm.org/D85678
2020-08-12 02:44:22 +08:00
add_subdirectory(InterfaceStub)
Split out the IRReader header and the utility functions it provides into its own library. These functions are bridging between the bitcode reader and the ll parser which are in different libraries. Previously we didn't have any good library to do this, and instead played fast and loose with a "header only" set of interfaces in the Support library. This really doesn't work well as evidenced by the recent attempt to add timing logic to the these routines. As part of this, make them normal functions rather than weird inline functions, and sink the implementation into the library. Also clean up the header to be nice and minimal. This requires updating lots of build system dependencies to specify that the IRReader library is needed, and several source files to not implicitly rely upon the header file to transitively include all manner of other headers. If you are using IRReader.h, this commit will break you (the header moved) and you'll need to also update your library usage to include 'irreader'. I will commit the corresponding change to Clang momentarily. llvm-svn: 177971
2013-03-26 10:25:37 +08:00
add_subdirectory(IRReader)
Move library stuff out of the toplevel CMakeLists.txt file. llvm-svn: 125968
2011-02-19 06:06:14 +08:00
add_subdirectory(CodeGen)
Move Object format code to lib/BinaryFormat. This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
2017-06-07 11:48:56 +08:00
add_subdirectory(BinaryFormat)
Move library stuff out of the toplevel CMakeLists.txt file. llvm-svn: 125968
2011-02-19 06:06:14 +08:00
add_subdirectory(Bitcode)
[Bitcode] Move Bitstream to a separate library This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/. This is needed to avoid a circular dependency when using the bitstream code for parsing optimization remarks. Since Bitcode uses Core for the IR part: libLLVMRemarks -> Bitcode -> Core and Core uses libLLVMRemarks to generate remarks (see IR/RemarkStreamer.cpp): Core -> libLLVMRemarks we need to separate the Bitstream and Bitcode part. For clang-doc, it seems that it doesn't need the whole bitcode layer, so I updated the CMake to only use the bitstream part. Differential Revision: https://reviews.llvm.org/D63899 llvm-svn: 365091
2019-07-04 06:40:07 +08:00
add_subdirectory(Bitstream)
[Dsymutil][Debuginfo][NFC] Reland: Refactor dsymutil to separate DWARF optimizing part. #2. Summary: This patch relands D71271. The problem with D71271 is that it has cyclic dependency: CodeGen->AsmPrinter->DebugInfoDWARF->CodeGen. To avoid cyclic dependency this patch puts implementation for DWARFOptimizer into separate library: lib/DWARFLinker. Thus the difference between this patch and D71271 is in that DWARFOptimizer renamed into DWARFLinker and it`s files are put into lib/DWARFLinker. Reviewers: JDevlieghere, friss, dblaikie, aprantl Reviewed By: JDevlieghere Subscribers: thegameg, merge_guards_bot, probinson, mgorny, hiraditya, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D71839
2019-12-21 00:23:31 +08:00
add_subdirectory(DWARFLinker)
Update compiler extension integration into the build system The approach here is to create a new (empty) component, `Extensions', where all statically compiled extensions dynamically register their dependencies. That way we're more natively compatible with LLVMBuild and llvm-config. Fixes: https://bugs.llvm.org/show_bug.cgi?id=44870 Differential Revision: https://reviews.llvm.org/D78192
2020-04-20 18:39:32 +08:00
add_subdirectory(Extensions)
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
add_subdirectory(Frontend)
Move library stuff out of the toplevel CMakeLists.txt file. llvm-svn: 125968
2011-02-19 06:06:14 +08:00
add_subdirectory(Transforms)
add_subdirectory(Linker)
add_subdirectory(Analysis)
Move LTO support library to a component, allowing it to be tested more reliably across platforms. Patch by Tom Roeder! llvm-svn: 191343
2013-09-25 07:52:22 +08:00
add_subdirectory(LTO)
Move library stuff out of the toplevel CMakeLists.txt file. llvm-svn: 125968
2011-02-19 06:06:14 +08:00
add_subdirectory(MC)
[llvm-mca] Move llvm-mca library to llvm/lib/MCA. Summary: See PR38731. Reviewers: andreadb Subscribers: mgorny, javed.absar, tschuett, gbedwell, andreadb, RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D55557 llvm-svn: 349332
2018-12-17 16:08:31 +08:00
add_subdirectory(MCA)
Move library stuff out of the toplevel CMakeLists.txt file. llvm-svn: 125968
2011-02-19 06:06:14 +08:00
add_subdirectory(Object)
Move ObjectYAML code to a new library. It is only ever used by obj2yaml and yaml2obj. No point in linking it everywhere. llvm-svn: 262368
2016-03-02 03:15:06 +08:00
add_subdirectory(ObjectYAML)
Copy clang/Driver/<Option parsing stuff> to llvm. llvm-svn: 169344
2012-12-05 08:29:32 +08:00
add_subdirectory(Option)
[OptRemarks] Make OptRemarks more generic: rename OptRemarks to Remarks Getting rid of the name "optimization remarks" for anything that involves handling remarks on the client side. It's safer to do this now, before we get stuck with that name in all the APIs and public interfaces we decide to export to users in the future. This renames llvm/tools/opt-remarks to llvm/tools/remarks-shlib, and now generates `libRemarks.dylib` instead of `libOptRemarks.dylib`. Differential Revision: https://reviews.llvm.org/D58535 llvm-svn: 355439
2019-03-06 04:45:17 +08:00
add_subdirectory(Remarks)
Sketch out a DWARF parser. This introduces a new library to LLVM: libDebugInfo. It will provide debug information parsing to LLVM. Much of the design and some of the code is taken from the LLDB project. It also contains an llvm-dwarfdump tool that can dump the abbrevs and DIEs from an object file. It can be used to write tests for DWARF input and output easily. llvm-svn: 139627
2011-09-14 03:42:23 +08:00
add_subdirectory(DebugInfo)
Move library stuff out of the toplevel CMakeLists.txt file. llvm-svn: 125968
2011-02-19 06:06:14 +08:00
add_subdirectory(ExecutionEngine)
add_subdirectory(Target)
add_subdirectory(AsmParser)
Introduce line editor library. This library will be used by clang-query. I can imagine LLDB becoming another client of this library, so I think LLVM is a sensible place for it to live. It wraps libedit, and adds tab completion support. The code is loosely based on the line editor bits in LLDB, with a few improvements: - Polymorphism for retrieving the list of tab completions, based on the concept pattern from the new pass manager. - Tab completion doesn't corrupt terminal output if the input covers multiple lines. Unfortunately this can only be done in a truly horrible way, as far as I can tell. But since the alternative is to implement our own line editor (which I don't think LLVM should be in the business of doing, at least for now) I think it may be acceptable. - Includes a fallback for the case where the user doesn't have libedit installed. Note that this uses C stdio, mainly because libedit also uses C stdio. Differential Revision: http://llvm-reviews.chandlerc.com/D2200 llvm-svn: 200595
2014-02-01 07:46:14 +08:00
add_subdirectory(LineEditor)
ProfileData: Introduce the InstrProfReader interface and a text reader This introduces the ProfileData library and updates llvm-profdata to use this library for reading profiles. InstrProfReader is an abstract base class that will be subclassed for both the raw instrprof data from compiler-rt and the efficient instrprof format that will be used for PGO. llvm-svn: 204482
2014-03-22 01:24:48 +08:00
add_subdirectory(ProfileData)
[PM] Create a separate library for high-level pass management code. This will provide the analogous replacements for the PassManagerBuilder and other code long term. This code is extracted from the opt tool currently, and I plan to extend it as I build up support for using the new pass manager in Clang and other places. Mailing this out for review in part to let folks comment on the terrible names here. A brief word about why I chose the names I did. The library is called "Passes" to try and make it clear that it is a high-level utility and where *all* of the passes come together and are registered in a common library. I didn't want it to be *limited* to a registry though, the registry is just one component. The class is a "PassBuilder" but this name I'm less happy with. It doesn't build passes in any traditional sense and isn't a Builder-style API at all. The class is a PassRegisterer or PassAdder, but neither of those really make a lot of sense. This class is responsible for constructing passes for registry in an analysis manager or for population of a pass pipeline. If anyone has a better name, I would love to hear it. The other candidate I looked at was PassRegistrar, but that doesn't really fit either. There is no register of all the passes in use, and so I think continuing the "registry" analog outside of the registry of pass *names* and *types* is a mistake. The objects themselves are just objects with the new pass manager. Differential Revision: http://reviews.llvm.org/D8054 llvm-svn: 231556
2015-03-07 17:02:36 +08:00
add_subdirectory(Passes)
[llvm-tapi] initial commit, supports ELF text stubs http://lists.llvm.org/pipermail/llvm-dev/2018-September/126472.html TextAPI is a library and accompanying tool that allows conversion between binary shared object stubs and textual counterparts. The motivations and uses cases for this are explained thoroughly in the llvm-dev proposal [1]. This initial commit proposes a potential structure for the TAPI library, also including support for reading/writing text-based ELF stubs (.tbe) in addition to preliminary support for reading binary ELF files. The goal for this patch is to ensure the project architecture appropriately welcomes integration of Mach-O stubbing from Apple's TAPI [2]. Added: - TextAPI library - .tbe read support - .tbe write (to raw_ostream) support [1] http://lists.llvm.org/pipermail/llvm-dev/2018-September/126472.html [2] https://github.com/ributzka/tapi Differential Revision: https://reviews.llvm.org/D53051 llvm-svn: 348170
2018-12-04 03:30:52 +08:00
add_subdirectory(TextAPI)
Move lib/LibDriver -> lib/ToolDrivers/llvm-lib. NFCI. This reorganisation prevents us from cluttering up the top-level lib directory with more driver libraries such as llvm-dlltool (see D29892). llvm-svn: 302995
2017-05-14 06:06:46 +08:00
add_subdirectory(ToolDrivers)
[XRay] Define the library for XRay trace logs Summary: In this change we move the definition of the log reading routines from the tools directory in LLVM to {include/llvm,lib}/XRay. We improve the documentation a little bit for the publicly accessible headers, and adjust the top-matter. This also leads to some refactoring and cleanup in the tooling code. In particular, we do the following: - Rename the class from LogReader to Trace, as it better represents the logical set of records as opposed to a log. - Use file type detection instead of asking the user to say what format the input file is. This allows us to keep the interface simple and encapsulate the logic of loading the data appropriately. In future changes we increase the API surface and write dedicated unit tests for the XRay library. Depends on D24376. Reviewers: dblaikie, echristo Subscribers: mehdi_amini, mgorny, llvm-commits, varno Differential Revision: https://reviews.llvm.org/D28345 llvm-svn: 291652
2017-01-11 14:39:09 +08:00
add_subdirectory(XRay)
Fix build errors LLVM tests are disabled. Original patch from alanbaker@google.com Fixes the error: CMake Error in <...>/llvm/cmake/modules/CMakeLists.txt: export called with target "LLVMTestingSupport" which requires target "gtest" that is not in the export set. This occurs when LLVM is embedded in a larger project, but is configured not to include tests. If testing is disabled gtest isn't available and LLVM fails to configure. Differential revision: https://reviews.llvm.org/D63097 llvm-svn: 365836
2019-07-12 06:08:35 +08:00
if (LLVM_INCLUDE_TESTS)
add_subdirectory(Testing)
endif()
Move manifest utils into separate lib, to reduce libxml2 deps. Summary: Previously were in support. Since many many things depend on support, were all forced to also depend on libxml2, which we only want in a few cases. This puts all the libxml2 deps in a separate lib to be used only in a few places. Reviewers: ruiu, thakis, rnk Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D35819 llvm-svn: 309070
2017-07-26 09:21:55 +08:00
add_subdirectory(WindowsManifest)
llvmbuildectomy - replace llvm-build by plain cmake No longer rely on an external tool to build the llvm component layout. Instead, leverage the existing `add_llvm_componentlibrary` cmake function and introduce `add_llvm_component_group` to accurately describe component behavior. These function store extra properties in the created targets. These properties are processed once all components are defined to resolve library dependencies and produce the header expected by llvm-config. Differential Revision: https://reviews.llvm.org/D90848
2020-10-10 00:41:21 +08:00
set(LLVMCONFIGLIBRARYDEPENDENCIESINC "${LLVM_BINARY_DIR}/tools/llvm-config/LibraryDependencies.inc")
llvmbuildectomy - support disabled native target
2020-11-13 22:49:27 +08:00
# Special components which don't have any source attached but aggregate other
# components
add_llvm_component_group(all-targets LINK_COMPONENTS ${LLVM_TARGETS_TO_BUILD})
add_llvm_component_group(Engine)
# The native target may not be enabled when cross compiling
if(TARGET ${LLVM_NATIVE_ARCH})
add_llvm_component_group(Native LINK_COMPONENTS ${LLVM_NATIVE_ARCH})
add_llvm_component_group(NativeCodeGen LINK_COMPONENTS ${LLVM_NATIVE_ARCH}CodeGen)
else()
add_llvm_component_group(Native)
add_llvm_component_group(NativeCodeGen)
endif()
# Component post-processing
llvmbuildectomy - replace llvm-build by plain cmake No longer rely on an external tool to build the llvm component layout. Instead, leverage the existing `add_llvm_componentlibrary` cmake function and introduce `add_llvm_component_group` to accurately describe component behavior. These function store extra properties in the created targets. These properties are processed once all components are defined to resolve library dependencies and produce the header expected by llvm-config. Differential Revision: https://reviews.llvm.org/D90848
2020-10-10 00:41:21 +08:00
LLVMBuildResolveComponentsLink()
LLVMBuildGenerateCFragment(OUTPUT ${LLVMCONFIGLIBRARYDEPENDENCIESINC})