aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorVy Nguyen <vyng@google.com>2020-02-10 15:56:48 -0500
committerVy Nguyen <vyng@google.com>2020-02-10 16:16:47 -0500
commit096ea1219e37d83184d10557df9c7709dbd926fd (patch)
treea24603fedb773a59a73dc0a6cdfff24799fe2b04
parent4c9ce042c54a4bccb4f0fc36e605e3df5be5a296 (diff)
downloadclang-096ea1219e37d83184d10557df9c7709dbd926fd.tar.gz
Delete deprecated doc.
The doc is now at https://android.googlesource.com/toolchain/llvm_android/+/master/README.md Test: docs Change-Id: I85f61d731e4c5509e768eb9cf5c25c8d6b7783bf
-rw-r--r--ToolchainPrebuilts.md203
1 files changed, 0 insertions, 203 deletions
diff --git a/ToolchainPrebuilts.md b/ToolchainPrebuilts.md
deleted file mode 100644
index f1b39e482f..0000000000
--- a/ToolchainPrebuilts.md
+++ /dev/null
@@ -1,203 +0,0 @@
-Updating Platform Toolchains
-============================
-
-For the latest version of this doc, please make sure to visit:
-[Android Clang/LLVM Toolchain Prebuilts Doc](https://android.googlesource.com/platform/external/clang/+/dev/ToolchainPrebuilts.md)
-
-Picking a good upstream revision
---------------------------------
-
-We generally like to follow along with upstream LLVM's Google stable tag:
-
-http://llvm.org/svn/llvm-project/llvm/tags/google/stable/
-
-You can use git/svn to query the latest tagged version to see what we will be
-validating next.
-
-
-Updating Toolchain Source
--------------------------
-
-The following process is done in the Android LLVM tree. To fetch the sources:
-
- repo init -u https://android.googlesource.com/platform/manifest -b llvm
-
- # Googlers, use
- repo init -u \
- persistent-https://android.git.corp.google.com/platform/manifest -b llvm
-
-Loop over llvm, clang, compiler-rt (in this order):
-
-1. We are working from a separate untracked/merged branch called *aosp/dev*.
-
- git branch -D working_dev
- repo start working_dev .
-
-2. **OPTIONAL FIXUPS**.
- These aren't really necessary if you remember to always keep *aosp/dev* and
- *aosp/master* synchronized otherwise, but very often someone will forget to
- merge back a change.
-
- 1. Grab the squashed commit that went into *aosp/master* and mark it
- committed to *aosp/dev* too.
-
- **Note**: If there were changes to *aosp/master* before the squashed
- commit, grab those changes (using step 2), before applying this step,
- and finally repeat step 2 for changes after the squashed commit.
-
- git branch -D clean_master
- git checkout -b clean_master <SHA_FOR_SQUASH>
- git checkout working_dev
- git merge -s ours clean_master
- git push aosp refs/heads/working_dev:refs/heads/dev
- git branch -D clean_master
-
- 2. Grab all outstanding changes that went into *aosp/master* and put them
- into *aosp/dev* too.
-
- git branch -D clean_master
- git checkout -b clean_master aosp/master
- git checkout working_dev
- git merge clean_master
- git push aosp refs/heads/working_dev:refs/heads/dev
- git branch -D clean_master
-
-3. Merge the upstream branch.
- Use `git log aosp/upsteam-master` to browse upstream commits and find a SHA.
-
- git merge <upstream_sha>
-
-4. Fix conflicts.
-
-5. Update build rules and commit that patch on top.
-
-6. Test everything before pushing.
-
-7. Submit your work to *aosp/dev*.
-
- git push aosp refs/heads/working_dev:refs/heads/dev
-
-8. Squash your work for *aosp/master*.
-
- repo start update_38 .
- git merge --squash working_dev
- git commit -a
- repo upload .
-
-9. Test everything before submitting the patch from the previous step.
-
-10. Grab the squashed commit and replay it in *aosp/dev*.
-
- repo sync .
- git remote update
- git branch -D clean_master
- git checkout -b clean_master aosp/master
- git checkout working_dev
-
- Use `-s ours` to ensure that we skip the squashed set of changes.
- If/when we forget this, we have to do it later.
-
- git merge -s ours clean_master
- git push aosp refs/heads/working_dev:refs/heads/dev
- git branch -D clean_master
-
-11. Clean up after our working branch.
-
- git checkout --detach
- git branch -D working_dev
-
-This works better because we can keep full history in *aosp/dev*, while
-maintaining easy reverts/commits through *aosp/master*.
-
-
-Generating New Prebuilts
-------------------------
-
-1. Run the toolchain build script. This will perform a two stage build and
- create a tarball of the final toolchain.
-
- python external/clang/build.py
-
-2. The just built toolchain can be tested in an existing AOSP tree by invoking
- make with:
-
- make \
- LLVM_PREBUILTS_VERSION=clang-dev \
- LLVM_PREBUILTS_BASE=/path/to/llvm/out/install
-
- This will use the just built toolchain rather than the one in **prebuilts/**.
- If you used something other than the default for `--build-name`, use
- `clang-$BUILD_NAME` instead of `clang-dev`.
-
-3. Once the updates have been verified, upload to gerrit, review, submit. The
- build server will pick up the changes and build them. The LLVM build page is
- http://go/clang-build. Sorry, Googlers only (for now) :(
-
-4. To update the platform compiler, download the selected package from the build
- server and extract them to the appropriate prebuilts directory. The new
- directory will be named "clang-BUILD\_NUMBER".
-
-5. Update `LLVM\_PREBUILTS\_VERSION` in `build/core/clang/config.mk` to match
- the new prebuilt directory. We typically keep around two versions of the
- toolchain in prebuilts so we can easily switch between them in the build
- system rather than needing to revert prebuilts. This also allows developers
- that need new toolchain features to take advantage of them locally while
- validation for the new compiler is still in progress.
-
-6. Rebuild/test everything one more time to ensure correctness.
-
- Make sure you check *goog/master* as well as *aosp/master*.
-
- There may be necessary fixups here, to handle .ll reading or other projects
- where new warnings/errors are firing.
-
- m -j48 checkbuild
-
-6. Upload the changes produced in **prebuilts/clang/host**.
- This may entail more than a simple `git commit -a`, so look at `git status`
- before finally uploading/committing.
-
- repo start updated_toolchain .
- git add clang-BUILD_NUMBER
- git commit
- repo upload --cbr .
-
-7. Submit CLs.
-
-
-Testing Checklist
------------------
-
-1. Do a checkbuild.
-2. Go to **external/llvm** and run `./android_test.sh` (no known failures as of
- 2015-10-08).
-3. Ensure successful build for all architectures: 32- and 64- bit ARM, x86 and
- Mips.
-4. Run ART host tests.
- This was broken by a rebase once, and worth testing after every rebase.
-
- croot && cd art && mma -j40 test-art-host
-
-5. Run ART device tests.
-
- croot && cd art && mma -j4 test-art-device
-
-
-Checklist for CLs
------------------
-
-The following projects will almost always have CLs as a part of the rebase.
-Depending on the changes in LLVM, there might be updates to other projects as
-well.
-
-* External projects
-
- * **external/clang**
- * **external/compiler-rt**
- * **external/llvm**
-
-* Prebuilts
-
- * **prebuilts/clang/host/darwin-x86/**
- * **prebuilts/clang/host/linux-x86/**
- * **prebuilts/clang/host/windows-x86/**