xref: /llvm-project/llvm/docs/BuildingADistribution.rst (revision 7226e7fd14c4e57f8ab5729990ee04bcdb1579af)
1===============================
2Building a Distribution of LLVM
3===============================
4
5.. contents::
6   :local:
7
8Introduction
9============
10
11This document is geared toward people who want to build and package LLVM and any
12combination of LLVM sub-project tools for distribution. This document covers
13useful features of the LLVM build system as well as best practices and general
14information about packaging LLVM.
15
16If you are new to CMake you may find the :doc:`CMake` or :doc:`CMakePrimer`
17documentation useful. Some of the things covered in this document are the inner
18workings of the builds described in the :doc:`AdvancedBuilds` document.
19
20General Distribution Guidance
21=============================
22
23When building a distribution of a compiler it is generally advised to perform a
24bootstrap build of the compiler. That means building a "stage 1" compiler with
25your host toolchain, then building the "stage 2" compiler using the "stage 1"
26compiler. This is done so that the compiler you distribute benefits from all the
27bug fixes, performance optimizations and general improvements provided by the
28new compiler.
29
30In deciding how to build your distribution there are a few trade-offs that you
31will need to evaluate. The big two are:
32
33#. Compile time of the distribution against performance of the built compiler
34
35#. Binary size of the distribution against performance of the built compiler
36
37The guidance for maximizing performance of the generated compiler is to use LTO,
38PGO, and statically link everything. This will result in an overall larger
39distribution, and it will take longer to generate, but it provides the most
40opportunity for the compiler to optimize.
41
42The guidance for minimizing distribution size is to dynamically link LLVM and
43Clang libraries into the tools to reduce code duplication. This will come at a
44substantial performance penalty to the generated binary both because it reduces
45optimization opportunity, and because dynamic linking requires resolving symbols
46at process launch time, which can be very slow for C++ code.
47
48.. _shared_libs:
49
50.. warning::
51  One very important note: Distributions should never be built using the
52  *BUILD_SHARED_LIBS* CMake option. That option exists for optimizing developer
53  workflow only. Due to design and implementation decisions, LLVM relies on
54  global data which can end up being duplicated across shared libraries
55  resulting in bugs. As such this is not a safe way to distribute LLVM or
56  LLVM-based tools.
57
58The simplest example of building a distribution with reasonable performance is
59captured in the DistributionExample CMake cache file located at
60clang/cmake/caches/DistributionExample.cmake. The following command will perform
61and install the distribution build:
62
63.. code-block:: console
64
65  $ cmake -G Ninja -C <path to clang>/cmake/caches/DistributionExample.cmake <path to LLVM source>
66  $ ninja stage2-distribution
67  $ ninja stage2-install-distribution
68
69Difference between ``install`` and ``install-distribution``
70-----------------------------------------------------------
71
72One subtle but important thing to note is the difference between the ``install``
73and ``install-distribution`` targets. The ``install`` target is expected to
74install every part of LLVM that your build is configured to generate except the
75LLVM testing tools. Alternatively the ``install-distribution`` target, which is
76recommended for building distributions, only installs specific parts of LLVM as
77specified at configuration time by *LLVM_DISTRIBUTION_COMPONENTS*.
78
79Additionally by default the ``install`` target will install the LLVM testing
80tools as the public tools. This can be changed well by setting
81*LLVM_INSTALL_TOOLCHAIN_ONLY* to ``On``. The LLVM tools are intended for
82development and testing of LLVM, and should only be included in distributions
83that support LLVM development.
84
85When building with *LLVM_DISTRIBUTION_COMPONENTS* the build system also
86generates a ``distribution`` target which builds all the components specified in
87the list. This is a convenience build target to allow building just the
88distributed pieces without needing to build all configured targets.
89
90.. _Multi-distribution configurations:
91
92Multi-distribution configurations
93---------------------------------
94
95The ``install-distribution`` target described above is for building a single
96distribution. LLVM's build system also supports building multiple distributions,
97which can be used to e.g. have one distribution containing just tools and
98another for libraries (to enable development). These are configured by setting
99the *LLVM_DISTRIBUTIONS* variable to hold a list of all distribution names
100(which conventionally start with an uppercase letter, e.g. "Development"), and
101then setting the *LLVM_<distribution>_DISTRIBUTION_COMPONENTS* variable to the
102list of targets for that distribution. For each distribution, the build system
103generates an ``install-${distribution}-distribution`` target, where
104``${distribution}`` is the name of the distribution in lowercase, to install
105that distribution.
106
107Each distribution creates its own set of CMake exports, and the target to
108install the CMake exports for a particular distribution for a project is named
109``${project}-${distribution}-cmake-exports``, where ``${project}`` is the name
110of the project in lowercase and ``${distribution}`` is the name of the
111distribution in lowercase, unless the project is LLVM, in which case the target
112is just named ``${distribution}-cmake-exports``. These targets need to be
113explicitly included in the *LLVM_<distribution>_DISTRIBUTION_COMPONENTS*
114variable in order to be included as part of the distribution.
115
116Unlike with the single distribution setup, when building multiple distributions,
117any components specified in *LLVM_RUNTIME_DISTRIBUTION_COMPONENTS* are not
118automatically added to any distribution. Instead, you must include the targets
119explicitly in some *LLVM_<distribution>_DISTRIBUTION_COMPONENTS* list.
120
121By default, each target can appear in multiple distributions; a target will be
122installed as part of all distributions it appears in, and it'll be exported by
123the last distribution it appears in (the order of distributions is the order
124they appear in *LLVM_DISTRIBUTIONS*). We also define some umbrella targets (e.g.
125``llvm-libraries`` to install all LLVM libraries); a target can appear in a
126different distribution than its umbrella, in which case the target will be
127exported by the distribution it appears in (and not the distribution its
128umbrella appears in). Set *LLVM_STRICT_DISTRIBUTIONS* to ``On`` if you want to
129enforce a target appearing in only one distribution and umbrella distributions
130being consistent with target distributions.
131
132We strongly encourage looking at ``clang/cmake/caches/MultiDistributionExample.cmake``
133as an example of configuring multiple distributions.
134
135Special Notes for Library-only Distributions
136--------------------------------------------
137
138One of the most powerful features of LLVM is its library-first design mentality
139and the way you can compose a wide variety of tools using different portions of
140LLVM. Even in this situation using *BUILD_SHARED_LIBS* is not supported. If you
141want to distribute LLVM as a shared library for use in a tool, the recommended
142method is using *LLVM_BUILD_LLVM_DYLIB*, and you can use *LLVM_DYLIB_COMPONENTS*
143to configure which LLVM components are part of libLLVM.
144Note: *LLVM_BUILD_LLVM_DYLIB* is not available on Windows.
145
146Options for Optimizing LLVM
147===========================
148
149There are four main build optimizations that our CMake build system supports.
150When performing a bootstrap build it is not beneficial to do anything other than
151setting *CMAKE_BUILD_TYPE* to ``Release`` for the stage-1 compiler. This is
152because the more intensive optimizations are expensive to perform and the
153stage-1 compiler is thrown away. All of the further options described should be
154set on the stage-2 compiler either using a CMake cache file, or by prefixing the
155option with *BOOTSTRAP_*.
156
157The first and simplest to use is the compiler optimization level by setting the
158*CMAKE_BUILD_TYPE* option. The main values of interest are ``Release`` or
159``RelWithDebInfo``. By default the ``Release`` option uses the ``-O3``
160optimization level, and ``RelWithDebInfo`` uses ``-O2``. If you want to generate
161debug information and use ``-O3`` you can override the
162*CMAKE_<LANG>_FLAGS_RELWITHDEBINFO* option for C and CXX.
163DistributionExample.cmake does this.
164
165Another easy to use option is Link-Time-Optimization. You can set the
166*LLVM_ENABLE_LTO* option on your stage-2 build to ``Thin`` or ``Full`` to enable
167building LLVM with LTO. These options will significantly increase link time of
168the binaries in the distribution, but it will create much faster binaries. This
169option should not be used if your distribution includes static archives, as the
170objects inside the archive will be LLVM bitcode, which is not portable.
171
172The :doc:`AdvancedBuilds` documentation describes the built-in tooling for
173generating LLVM profiling information to drive Profile-Guided-Optimization. The
174in-tree profiling tests are very limited, and generating the profile takes a
175significant amount of time, but it can result in a significant improvement in
176the performance of the generated binaries.
177
178In addition to PGO profiling we also have limited support in-tree for generating
179linker order files. These files provide the linker with a suggested ordering for
180functions in the final binary layout. This can measurably speed up clang by
181physically grouping functions that are called temporally close to each other.
182The current tooling is only available on Darwin systems with ``dtrace(1)``. It
183is worth noting that dtrace is non-deterministic, and so the order file
184generation using dtrace is also non-deterministic.
185
186Options for Reducing Size
187=========================
188
189.. warning::
190  Any steps taken to reduce the binary size will come at a cost of runtime
191  performance in the generated binaries.
192
193The simplest and least significant way to reduce binary size is to set the
194*CMAKE_BUILD_TYPE* variable to ``MinSizeRel``, which will set the compiler
195optimization level to ``-Os`` which optimizes for binary size. This will have
196both the least benefit to size and the least impact on performance.
197
198The most impactful way to reduce binary size is to dynamically link LLVM into
199all the tools. This reduces code size by decreasing duplication of common code
200between the LLVM-based tools. This can be done by setting the following two
201CMake options to ``On``: *LLVM_BUILD_LLVM_DYLIB* and *LLVM_LINK_LLVM_DYLIB*.
202
203.. warning::
204  Distributions should never be built using the *BUILD_SHARED_LIBS* CMake
205  option. (:ref:`See the warning above for more explanation <shared_libs>`.).
206
207Relevant CMake Options
208======================
209
210This section provides documentation of the CMake options that are intended to
211help construct distributions. This is not an exhaustive list, and many
212additional options are documented in the :doc:`CMake` page. Some key options
213that are already documented include: *LLVM_TARGETS_TO_BUILD*, *LLVM_ENABLE_PROJECTS*,
214*LLVM_ENABLE_RUNTIMES*, *LLVM_BUILD_LLVM_DYLIB*, and *LLVM_LINK_LLVM_DYLIB*.
215
216**LLVM_ENABLE_RUNTIMES**:STRING
217  When building a distribution that includes LLVM runtime projects (i.e. libcxx,
218  compiler-rt, libcxxabi, libunwind...), it is important to build those projects
219  with the just-built compiler.
220
221**LLVM_DISTRIBUTION_COMPONENTS**:STRING
222  This variable can be set to a semi-colon separated list of LLVM build system
223  components to install. All LLVM-based tools are components, as well as most
224  of the libraries and runtimes. Component names match the names of the build
225  system targets.
226
227**LLVM_DISTRIBUTIONS**:STRING
228  This variable can be set to a semi-colon separated list of distributions. See
229  the :ref:`Multi-distribution configurations` section above for details on this
230  and other CMake variables to configure multiple distributions.
231
232**LLVM_RUNTIME_DISTRIBUTION_COMPONENTS**:STRING
233  This variable can be set to a semi-colon separated list of runtime library
234  components. This is used in conjunction with *LLVM_ENABLE_RUNTIMES* to specify
235  components of runtime libraries that you want to include in your distribution.
236  Just like with *LLVM_DISTRIBUTION_COMPONENTS*, component names match the names
237  of the build system targets.
238
239**LLVM_DYLIB_COMPONENTS**:STRING
240  This variable can be set to a semi-colon separated name of LLVM library
241  components. LLVM library components are either library names with the LLVM
242  prefix removed (i.e. Support, Demangle...), LLVM target names, or special
243  purpose component names. The special purpose component names are:
244
245  #. ``all`` - All LLVM available component libraries
246  #. ``Native`` - The LLVM target for the Native system
247  #. ``AllTargetsAsmParsers`` - All the included target ASM parsers libraries
248  #. ``AllTargetsDescs`` - All the included target descriptions libraries
249  #. ``AllTargetsDisassemblers`` - All the included target dissassemblers libraries
250  #. ``AllTargetsInfos`` - All the included target info libraries
251
252**LLVM_INSTALL_TOOLCHAIN_ONLY**:BOOL
253  This option defaults to ``Off``: when set to ``On`` it removes many of the
254  LLVM development and testing tools as well as component libraries from the
255  default ``install`` target. Including the development tools is not recommended
256  for distributions as many of the LLVM tools are only intended for development
257  and testing use.
258