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.