1 Android Clang/LLVM 2 ================== 3 4 Platform Projects 5 ----------------- 6 7 The LLVM toolchain is primarily composed of the following projects: 8 9 * **external/clang** 10 * **external/compiler-rt** 11 * **external/llvm** 12 13 Each of these projects has three important branches: 14 15 * *aosp/master* 16 17 This is the branch that will be present in most platform trees. As such, 18 platform components that use clang or LLVM will build against the headers and 19 libraries in this branch. 20 21 This branch does not contain a full history. Updates to this are done via a 22 squashed merge from the *dev* branch. Aside from updates, patches usually 23 shouldn't be submitted to this branch. Any that are will need to be 24 cherry-picked to *dev*. 25 26 * *aosp/dev* 27 28 The primary purpose of this branch is allowing us to decouple the platform 29 compilers from RenderScript and other platform components that depend on LLVM 30 libraries. This means we can update the platform compilers even if 31 RenderScript will need substantial modification for API changes. 32 33 Updates are performed in this branch, and the platform compilers are built 34 from this branch. 35 36 * *aosp/upstream-master* 37 38 This branch is an automatically updated direct mirror of the upstream master 39 branch. This is a read only branch that is the merge source for updates to 40 *dev*. 41 42 43 Development Flow 44 ---------------- 45 46 Rebases take place in the **aosp/llvm** tree. This tree is a manifest that uses 47 the appropriate *dev* branches of each LLVM project and contains only the 48 projects needed to build the platform compilers. Updates are done by merging 49 from the *aosp/upstream-master* branch. 50 51 Conflicts are resolved manually and then a patch is produced to adapt 52 Android.mk files (as well as to add/delete any updated source files). 53 Prebuilts are then generated using these projects and placed into the proper 54 **prebuilts/clang/host** subprojects. 55 56 The prebuilt projects contain multiple versions to make it easy to check in a 57 new compiler that may not be ready to be enabled by default. Each new toolchain 58 will add the following paths: 59 60 prebuilts/clang/host/linux-x86/clang-$BUILD_NUMBER 61 prebuilts/clang/host/darwin-x86/clang-$BUILD_NUMBER 62 prebuilts/clang/host/windows-x86/clang-$BUILD_NUMBER 63 64 In order to prepare for the actual rebase (including updating dependent 65 projects), we will copy each **external/** *aosp/dev* project to its 66 corresponding **external/** *aosp/master* project as a squashed single CL. 67 This makes rollbacks simpler, and it also reduces churn on the Android build 68 servers. 69 This also has the side effect of not spamming non-Android @google.com 70 committers to upstream LLVM projects, since their commits will be batched up 71 into a single copy commit on each tracked **external/** project. 72 73 Prebuilts for llvm-rs-cc and bcc\_compat also need to be generated for 74 **prebuilts/sdk**. 75 This is done by running **frameworks/rs/update\_rs\_prebuilts.sh** on both Mac 76 and Linux. This is done from the normal AOSP platform tree rather than the LLVM 77 tree. 78 After this completes, the **prebuilts/sdk** project will have a prepared 79 branch/CL that can be uploaded for review/commit. 80 81 82 Fixing Bugs 83 ----------- 84 85 If we find a host-side bug that needs to be fixed, it may trigger an update of 86 the host prebuilts (i.e. rebase). 87 Device-side fixes can be pushed directly to **external/** *aosp/master* and then 88 copied to **external/** *aosp/dev* to speed up the process (assuming that it 89 doesnt affect the host builds). 90 91 92 Looking at Upstream 93 ------------------- 94 95 The upstream repositories are automatically mirrored to the 96 *aosp/upstream-master* branch. Update with `git fetch aosp upstream-master`. 97 98 99 Guides for Updating Toolchains 100 ------------------------------ 101 102 * [Updating platform toolchains](ToolchainPrebuilts.md) 103 * [Updating RenderScript prebuilts](RenderScriptPrebuilts.md) 104
