110 lines
4.5 KiB
ReStructuredText
110 lines
4.5 KiB
ReStructuredText
.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
|
|
|
|
Speeding Up a Build
|
|
*******************
|
|
|
|
Build time can be an issue. By default, the build system uses simple
|
|
controls to try and maximize build efficiency. In general, the default
|
|
settings for all the following variables result in the most efficient
|
|
build times when dealing with single socket systems (i.e. a single CPU).
|
|
If you have multiple CPUs, you might try increasing the default values
|
|
to gain more speed. See the descriptions in the glossary for each
|
|
variable for more information:
|
|
|
|
- :term:`BB_NUMBER_THREADS`:
|
|
The maximum number of threads BitBake simultaneously executes.
|
|
|
|
- :term:`BB_NUMBER_PARSE_THREADS`:
|
|
The number of threads BitBake uses during parsing.
|
|
|
|
- :term:`PARALLEL_MAKE`: Extra
|
|
options passed to the ``make`` command during the
|
|
:ref:`ref-tasks-compile` task in
|
|
order to specify parallel compilation on the local build host.
|
|
|
|
- :term:`PARALLEL_MAKEINST`:
|
|
Extra options passed to the ``make`` command during the
|
|
:ref:`ref-tasks-install` task in
|
|
order to specify parallel installation on the local build host.
|
|
|
|
As mentioned, these variables all scale to the number of processor cores
|
|
available on the build system. For single socket systems, this
|
|
auto-scaling ensures that the build system fundamentally takes advantage
|
|
of potential parallel operations during the build based on the build
|
|
machine's capabilities.
|
|
|
|
Following are additional factors that can affect build speed:
|
|
|
|
- File system type: The file system type that the build is being
|
|
performed on can also influence performance. Using ``ext4`` is
|
|
recommended as compared to ``ext2`` and ``ext3`` due to ``ext4``
|
|
improved features such as extents.
|
|
|
|
- Disabling the updating of access time using ``noatime``: The
|
|
``noatime`` mount option prevents the build system from updating file
|
|
and directory access times.
|
|
|
|
- Setting a longer commit: Using the "commit=" mount option increases
|
|
the interval in seconds between disk cache writes. Changing this
|
|
interval from the five second default to something longer increases
|
|
the risk of data loss but decreases the need to write to the disk,
|
|
thus increasing the build performance.
|
|
|
|
- Choosing the packaging backend: Of the available packaging backends,
|
|
IPK is the fastest. Additionally, selecting a singular packaging
|
|
backend also helps.
|
|
|
|
- Using ``tmpfs`` for :term:`TMPDIR`
|
|
as a temporary file system: While this can help speed up the build,
|
|
the benefits are limited due to the compiler using ``-pipe``. The
|
|
build system goes to some lengths to avoid ``sync()`` calls into the
|
|
file system on the principle that if there was a significant failure,
|
|
the :term:`Build Directory` contents could easily be rebuilt.
|
|
|
|
- Inheriting the :ref:`ref-classes-rm-work` class:
|
|
Inheriting this class has shown to speed up builds due to
|
|
significantly lower amounts of data stored in the data cache as well
|
|
as on disk. Inheriting this class also makes cleanup of
|
|
:term:`TMPDIR` faster, at the
|
|
expense of being easily able to dive into the source code. File
|
|
system maintainers have recommended that the fastest way to clean up
|
|
large numbers of files is to reformat partitions rather than delete
|
|
files due to the linear nature of partitions. This, of course,
|
|
assumes you structure the disk partitions and file systems in a way
|
|
that this is practical.
|
|
|
|
Aside from the previous list, you should keep some trade offs in mind
|
|
that can help you speed up the build:
|
|
|
|
- Remove items from
|
|
:term:`DISTRO_FEATURES`
|
|
that you might not need.
|
|
|
|
- Exclude debug symbols and other debug information: If you do not need
|
|
these symbols and other debug information, disabling the ``*-dbg``
|
|
package generation can speed up the build. You can disable this
|
|
generation by setting the
|
|
:term:`INHIBIT_PACKAGE_DEBUG_SPLIT`
|
|
variable to "1".
|
|
|
|
- Disable static library generation for recipes derived from
|
|
``autoconf`` or ``libtool``: Following is an example showing how to
|
|
disable static libraries and still provide an override to handle
|
|
exceptions::
|
|
|
|
STATICLIBCONF = "--disable-static"
|
|
STATICLIBCONF:sqlite3-native = ""
|
|
EXTRA_OECONF += "${STATICLIBCONF}"
|
|
|
|
.. note::
|
|
|
|
- Some recipes need static libraries in order to work correctly
|
|
(e.g. ``pseudo-native`` needs ``sqlite3-native``). Overrides,
|
|
as in the previous example, account for these kinds of
|
|
exceptions.
|
|
|
|
- Some packages have packaging code that assumes the presence of
|
|
the static libraries. If so, you might need to exclude them as
|
|
well.
|
|
|