Source code
Revision control
Copy as Markdown
Other Tools
build-clang.py
==============
A script to build clang from source.
```
usage: build-clang.py [-h] -c CONFIG [--clean]
optional arguments:
-h, --help show this help message and exit
-c CONFIG, --config CONFIG
Clang configuration file
--clean Clean the build directory
```
Pre-requisites
--------------
* Working build toolchain.
* git
* CMake
* Ninja
* Python 2.7 and 3
Please use the latest available CMake for your platform to avoid surprises.
Config file format
------------------
build-clang.py accepts a JSON config format with the following fields:
* stages: Use 1, 2, 3 or 4 to select different compiler stages. The default is 2.
* cc: Path to the bootstraping C Compiler.
* cxx: Path to the bootstraping C++ Compiler.
* as: Path to the assembler tool.
* ar: Path to the library archiver tool.
* ranlib: Path to the ranlib tool (optional).
* ld: Path to the linker.
* patches: Optional list of patches to apply.
* build_type: The type of build to make. Supported types: Release, Debug, RelWithDebInfo or MinSizeRel.
* targets: The targets supported by the final stage LLVM/clang.
* build_clang_tidy: Whether to build clang-tidy with the Mozilla checks imported. The default is false.
* osx_cross_compile: Whether to invoke CMake for OS X cross compile builds.
* assertions: Whether to enable LLVM assertions. The default is false.
* pgo: Whether to build with PGO (requires stages == 4). The default is false.
The revisions are defined in taskcluster/kinds/fetch/toolchains.yml. They are usually commit sha1s corresponding to upstream tags.
Environment Variables
---------------------
The following environment variables are used for cross-compile builds targeting OS X on Linux.
* OSX_SYSROOT: Path to the OS X SDK directory for cross compile builds.
Writing Patches
---------------
Patches to Clang should be registered in ``clang-$n.json`` for patches to Clang ``$n.x``. They are applied in order.
When backporting patches from upstream, please use the output of ``git describe $rev`` to name the patch file, where ``$rev`` is the original revision upstream.
When reverting a commit from upstream, say ``$reverted_rev``, please name the patch ``revert-$(git describe $reverted_rev)``.
When adding a downstream patch, please suffix the patch with ``_clang_$n.patch``, where ``$n`` is the first version of Clang for which that patch needs to be applied. In the very common situation where the patch needs to be applied on the ``main`` branch, use the current development version number of Clang as ``$n``.
Patches in ``clang-$n.json`` are ordered following the following rules:
1. Patches that start with ``revert-llvmorg`` are in *reverse* `natural sort order <https://en.wikipedia.org/wiki/Natural_sort_order>`_.
2. Patches that start with ``llvmorg`` are in natural sort order.
3. Patches that correspond to an upstream *revert* come before the *cherry-picked* ones.
Other patches do not follow any specific ordering rule.