forked from bazel-contrib/toolchains_llvm
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
bazel: Add support for darwin arm64 (M1 builds)
We've been using the bazel-toolchain library so we can use our custom LLVM toolchain. This was working perfectly on CI because we compile on Linux there. On our local M1 machines this was falling back on our xcode compiler instead of the custom toolchain because bazel-toolchain doesn't have support for the darwin-arm64 configuration. There is an existing GitHub issue about this (bazel-contrib#88) with a lot of activity but nothing landed. There also seemed to be some outstanding PRs, but they are complete rewrites; and it's not clear when they would land. My guess is that we may be able to drop our patches at some point, but we shouldn't wait for it. The main changes here are as follows: * We add support for a darwin-arm64 toolchain to bazel-toolchain. * This requires some additional configuration to handle the various ridiculous goop that macOS builds need; bazel already has toolchain support for this, so most of it is copied from the bazelbuild repo. It would be great to upstream this, but that might be a significant effort. * It appears that bazel-toolchain handled everything using the `unix_cc_toolchain_config`, which only had limited supported for Objective C. Since we need to fully be able to compile objective C applications, we need to include `osx_cc_toolchain_config` as well. * The `osx_cc_toolchain_config` uses a clang wrapper called `wrapped_clang` and `wrapped_clang_pp`. This is written as a C++ source file for some reason, so it needs to be compiled as part of the toolchain build. This wrapper forwards to xcode clang/clang++ by default, but we want to forward to our own toolchain instead. So we have to modify the wrapper slightly to look at some environment variables to determine where the real toolchain is. * The clang compiler includes some directories by default, specifically ones that are included with the compiler. This works if you run the toolchain manually, but bazel doesn't like this because it wants to make sure that it knows about all included headers. Normally you should be able to use the `cxx_builtin_include_directories` attribute to notify bazel about these directories, but it doesn't seem to work. It seems that the problem may be that the included paths are absolute instead of relative, so they don't appear to be the same path to bazel. Using clang's `-no-canonical-prefixes` flag is meant to fix this, but it didn't seem to work for me. As an alternate workaround, I made sure to include all the built-in directories again via `-isystem` so that the paths match exactly.
- Loading branch information
Showing
8 changed files
with
3,624 additions
and
38 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.