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

55 lines
1023 B
Plaintext
Raw Normal View History

build: Add initial cut at LLVMBuild.txt files. llvm-svn: 143634
2011-11-04 02:53:17 +08:00
;===- ./lib/LLVMBuild.txt --------------------------------------*- Conf -*--===;
;
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
; Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
; See https://llvm.org/LICENSE.txt for license information.
; SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
build: Add initial cut at LLVMBuild.txt files. llvm-svn: 143634
2011-11-04 02:53:17 +08:00
;
;===------------------------------------------------------------------------===;
;
; This is an LLVMBuild description file for the components in this subdirectory.
;
; For more information on the LLVMBuild system, please see:
;
; http://llvm.org/docs/LLVMBuild.html
;
;===------------------------------------------------------------------------===;
LLVMBuild: Introduce a common section which currently has a list of the subdirectories to traverse into. - Originally I wanted to avoid this and just autoscan, but this has one key flaw in that new subdirectories can not automatically trigger a rerun of the llvm-build tool. This is particularly a pain when switching back and forth between trees where one has added a subdirectory, as the dependencies will tend to be wrong. This will also eliminates FIXME implicitly. llvm-svn: 146436
2011-12-13 06:45:54 +08:00
[common]
Wrap some long lines in LLVMBuild files. NFC As suggested by jroelofs in a prior review (D9752), it makes sense to generally prefer multi-line format. llvm-svn: 239632
2015-06-13 02:44:57 +08:00
subdirectories =
Analysis
AsmParser
Bitcode
CodeGen
DebugInfo
Add an c++ itanium demangler to llvm. This adds a copy of the demangler in libcxxabi. The code also has no dependencies on anything else in LLVM. To enforce that I added it as another library. That way a BUILD_SHARED_LIBS will fail if anyone adds an use of StringRef for example. The no llvm dependency combined with the fact that this has to build on linux, OS X and Windows required a few changes to the code. In particular: No constexpr. No alignas On OS X at least this library has only one global symbol: __ZN4llvm16itanium_demangleEPKcPcPmPi My current plan is: Commit something like this Change lld to use it Change lldb to use it as the fallback Add a few #ifdefs so that exactly the same file can be used in libcxxabi to export abi::__cxa_demangle. Once the fast demangler in lldb can handle any names this implementation can be replaced with it and we will have the one true demangler. llvm-svn: 280732
2016-09-07 03:16:48 +08:00
Demangle
Wrap some long lines in LLVMBuild files. NFC As suggested by jroelofs in a prior review (D9752), it makes sense to generally prefer multi-line format. llvm-svn: 239632
2015-06-13 02:44:57 +08:00
ExecutionEngine
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
FuzzMutate
Wrap some long lines in LLVMBuild files. NFC As suggested by jroelofs in a prior review (D9752), it makes sense to generally prefer multi-line format. llvm-svn: 239632
2015-06-13 02:44:57 +08:00
LineEditor
Linker
IR
IRReader
LTO
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
MCA
Wrap some long lines in LLVMBuild files. NFC As suggested by jroelofs in a prior review (D9752), it makes sense to generally prefer multi-line format. llvm-svn: 239632
2015-06-13 02:44:57 +08:00
Object
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
BinaryFormat
Add LLVMBuild for ObjectYAML. Should fix the DBUILD_SHARED_LIBS bots. llvm-svn: 262396
2016-03-02 05:29:33 +08:00
ObjectYAML
Wrap some long lines in LLVMBuild files. NFC As suggested by jroelofs in a prior review (D9752), it makes sense to generally prefer multi-line format. llvm-svn: 239632
2015-06-13 02:44:57 +08:00
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
Remarks
Wrap some long lines in LLVMBuild files. NFC As suggested by jroelofs in a prior review (D9752), it makes sense to generally prefer multi-line format. llvm-svn: 239632
2015-06-13 02:44:57 +08:00
Passes
ProfileData
Support
TableGen
[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
TextAPI
Wrap some long lines in LLVMBuild files. NFC As suggested by jroelofs in a prior review (D9752), it makes sense to generally prefer multi-line format. llvm-svn: 239632
2015-06-13 02:44:57 +08:00
Target
[gtest] Create a shared include directory for gtest utilities. Many times unit tests for different libraries would like to use the same helper functions for checking common types of errors. This patch adds a common library with helpers for testing things in Support, and introduces helpers in here for integrating the llvm::Error and llvm::Expected<T> classes with gtest and gmock. Normally, we would just be able to write: EXPECT_THAT(someFunction(), succeeded()); but due to some quirks in llvm::Error's move semantics, gmock doesn't make this easy, so two macros EXPECT_THAT_ERROR() and EXPECT_THAT_EXPECTED() are introduced to gloss over the difficulties. Consider this an exception, and possibly only temporary as we look for ways to improve this. Differential Revision: https://reviews.llvm.org/D33059 llvm-svn: 305395
2017-06-15 00:41:50 +08:00
Testing
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
ToolDrivers
Wrap some long lines in LLVMBuild files. NFC As suggested by jroelofs in a prior review (D9752), it makes sense to generally prefer multi-line format. llvm-svn: 239632
2015-06-13 02:44:57 +08:00
Transforms
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
WindowsManifest
[XRay] Clean up XRay build configuration Summary: This change spans both LLVM and compiler-rt, where we do the following: - Add XRay to the LLVMBuild system, to allow for distributing the XRay trace loading library along with the LLVM distributions. - Use `llvm-config` better in the compiler-rt XRay implementation, to depend on the potentially already-distributed LLVM XRay library. While this is tested with the standalone compiler-rt build, it does require that the LLVMXRay library (and LLVMSupport as well) are available during the build. In case the static libraries are available, the unit tests will build and work fine. We're still having issues with attempting to use a shared library version of the LLVMXRay library since the shared library might not be accessible from the standard shared library lookup paths. The larger change here is the inclusion of the LLVMXRay library in the distribution, which allows for building tools around the XRay traces and profiles that the XRay runtime already generates. Reviewers: echristo, beanz Subscribers: mgorny, hiraditya, mboerger, llvm-commits Differential Revision: https://reviews.llvm.org/D52349 llvm-svn: 342859
2018-09-24 13:28:01 +08:00
XRay
LLVMBuild: Introduce a common section which currently has a list of the subdirectories to traverse into. - Originally I wanted to avoid this and just autoscan, but this has one key flaw in that new subdirectories can not automatically trigger a rerun of the llvm-build tool. This is particularly a pain when switching back and forth between trees where one has added a subdirectory, as the dependencies will tend to be wrong. This will also eliminates FIXME implicitly. llvm-svn: 146436
2011-12-13 06:45:54 +08:00
build: Add initial cut at LLVMBuild.txt files. llvm-svn: 143634
2011-11-04 02:53:17 +08:00
[component_0]
type = Group
name = Libraries
parent = $ROOT