diff --git a/llvm/docs/LLVMBuild.html b/llvm/docs/LLVMBuild.html new file mode 100644 index 000000000000..904d0e56e414 --- /dev/null +++ b/llvm/docs/LLVMBuild.html @@ -0,0 +1,328 @@ + + +
+ +This document describes the LLVMBuild organization and files which + we use to describe parts of the LLVM ecosystem. For description of specific + LLVMBuild related tools, please see the command guide.
+ +LLVM is designed to be a modular set of libraries which can be flexibly + mixed together in order to build a variety of tools, like compilers, JITs, + custom code generators, optimization passes, interpreters, and so on. Related + projects in the LLVM system like Clang and LLDB also tend to follow this + philosophy.
+ +In order to support this usage style, LLVM has a fairly strict structure as + to how the source code and various components are organized. The + LLVMBuild.txt files are the explicit specification of that structure, + and are used by the build systems and other tools in order to develop the LLVM + project.
+The source code for LLVM projects using the LLVMBuild system (LLVM, Clang, + and LLDB) is organized into components, which define the separate + pieces of functionality that make up the project. These projects may consist + of many libraries, associated tools, build tools, or other utility tools (for + example, testing tools).
+ +For the most part, the project contents are organized around defining one + main component per each subdirectory. Each such directory contains + an LLVMBuild.txt which contains the component definitions.
+ +The component descriptions for the project as a whole are automatically + gathered by the LLVMBuild tools. The tools automatically traverse the source + directory structure to find all of the component description files. NOTE: For + performance/sanity reasons, we only traverse into subdirectories when the + parent itself contains an LLVMBuild.txt description file.
+The LLVMBuild files themselves are just a declarative way to describe the + project structure. The actual building of the LLVM project is handled by + another build system (currently we support + both Makefiles + and CMake.
+ +The build system implementation will load the relevant contents of the + LLVMBuild files and use that to drive the actual project build. Typically, the + build system will only need to load this information at "configure" time, and + use it to generative native information. Build systems will also handle + automatically reconfiguring their information when the contents of + the LLVMBuild.txt files change.
+ +Developers generally are not expected to need to be aware of the details of + how the LLVMBuild system is integrated into their build. Ideally, LLVM + developers who are not working on the build system would only ever need to + modify the contents of the LLVMBuild.txt description files (although we + have not reached this goal yet).
+As mentioned earlier, LLVM projects are organized into + logical components. Every component is typically grouped into it's + own subdirectory. Generally, a component is organized around a coherent group + of sources which have some kind of clear API separation from other parts of + the code.
+ +LLVM primarily uses the following types of components:
+Components are described using LLVMBuild.txt files in the + directories that define the component. See + the Format Reference section for information on + the exact format of these files.
+LLVMBuild files are written in a simple variant of the INI or configuration + file format (Wikipedia + entry). The format defines a list of sections each of which may contain + some number of properties. A simple example of the file format is below:
++; Comments start with a semi-colon. + +; Sections are declared using square brackets. +[component 0] + +; Properties are declared using '=' and are contained in the previous section. +; +; We support simple scalar values and list values, where items are separated by +; spaces. There is no support for quoting, and so property values may not contain +; spaces. +property_name = property_value +list_property_name = value_1 value_2 ... value_n ++
LLVMBuild files are expected to define a strict set of section and + properties. An typical component description file for a library + component would look typically look like the following example:
++[component_0] +type = Library +name = Linker +parent = Libraries +required_libraries = Archive BitReader Core Support TransformUtils ++
A full description of the exact sections and properties which are allowed + follows.
+ +Each file may define multiple components. Each component is described by a + section who name starts with "component". The remainder of the section name is + ignored, but each section name must be unique. Typically components are just + number in order for files with multiple components ("component_0", + "component_1", and so on).
+ +
Section names not matches this format are currently + unused and are disallowed.
+ +Every component is defined by the properties in the section. The exact list + of properties that are allowed depends on the component + type. Components may not define any properties other than those + expected by the component type.
+ +Every component must define the following properties:
+The type of the component. Supported component types are + detailed below. Most components will define additional properties which + may be required or optional.
The name of the component. Names are required to be unique + across the entire project.
The name of the logical parent of the component. Components are + organized into a logical tree to make it easier to navigate and organize + groups of components. The parent's have no semantics as far as the project + build is concerned, however. Typically, the parent will be the main + component of the parent directory.
+ + + +Components may reference the root pseudo component using '$ROOT' to + indicate they should logically be grouped at the top-level.
+Components may define the following properties:
+If specified, a list of names of components which must be built + prior to this one. This should only be exactly those components which + produce some tool or source code required for building the + component.
+ +NOTE: Group and LibraryGroup components have no semantics for + the actual build, and are not allowed to specify dependencies.
The following section lists the available component types, as well as the + properties which are associated with that component.
+ +Group components exist purely to allow additional arbitrary structuring + of the logical components tree. For example, one might define a + "Libraries" group to hold all of the root library components.
+ +Group components have no additionally properties.
+Library components define an individual library which should be built + from the source code in the component directory.
+ +Components with this type use the following properties:
+If given, the name to use for the actual library file on disk. If + not given, the name is derived from the component name + itself.
If given, a list of the names of Library or LibraryGroup components + which must also be linked in whenever this library is used. That is, + the link time dependencies for this component. When tools are built, + the build system will include the transitive closer of + all required_libraries for the components the tool needs.
If given, a list of the names of LibraryGroup components which this + component is also part of. This allows nesting groups of + components. For example, the X86 target might define a library + group for all of the X86 components. That library group might + then be included in the all-targets library group.
LibraryGroup components are a mechanism to allow easy definition of + useful sets of related components. In particular, we use them to easily + specify things like "all targets", or "all assembly printers".
+ +Components with this type use the following properties:
+See the Library type for a description of this property.
See the Library type for a description of this property.
Tool components define standalone command line tools which should be + built from the source code in the component directory and linked.
+ +Components with this type use the following properties:
+If given, a list of the names of Library or LibraryGroup components + which this tool is required to be linked with. NOTE: The values + should be the component names, which may not always match up with the + actual library names on disk.
+ +Build systems are expected to properly include all of the libraries + required by the linked components (i.e., the transitive closer + of required_libraries).
+ +Build systems are also expected to understand that those library + components must be built prior to linking -- they do not also need to + be listed under dependencies.
BuildTool components are like Tool components, except that the tool is + supposed to be built for the platform where the build is running (instead + of that platform being targetted). Build systems are expected to handle + the fact that required libraries may need to be built for multiple + platforms in order to be able to link this tool.
+ +BuildTool components currently use the exact same properties as Tool + components, the type distinction is only used to differentiate what the + tool is built for.
+