-
-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Track unix_cc_toolchain_config from bazel's tools/cpp #23
Comments
In general, this project is now lagging behind https://source.bazel.build/bazel/+/master:tools/cpp/unix_cc_toolchain_config.bzl. Maybe I should also try to just use that rule directly without copy pasting code from there. I am going to repurpose this issue towards that. |
Thanks @siddharthab ! |
ThinLTO has now made it to @bazel_tools//tools/cpp:unix_cc_toolchain_config.bzl in bazel 1.0. So we can now refactor our code to depend on the rule there for this as well as other features. |
The standard |
…_tools (See bazel-contrib#23). Since `@bazel_tools//tools/cpp:unix_cc_toolchain_config.bzl:cc_toolchain_config` is a rule, our `cc_toolchain_config` needs to become a macro instead of a rule. Luckily we actually can do this without introducing any breaking changes. Other than the discrepancies listed within (the things marked with `## NOTE:` — make vars and framework paths) everything seemed to just fall into place. So far it seems to _just work_ 🤞.
…_tools (See bazel-contrib#23). Since `@bazel_tools//tools/cpp:unix_cc_toolchain_config.bzl:cc_toolchain_config` is a rule, our `cc_toolchain_config` needs to become a macro instead of a rule. Luckily we actually can do this without introducing any breaking changes. Other than the discrepancies listed within (the things marked with `## NOTE:` — make vars and framework paths) everything seemed to just fall into place. So far it seems to _just work_ 🤞.
Closes #23. Notes: 1. `cc_toolchain_config` is now a macro. 2. [Make variables](https://github.com/grailbio/bazel-toolchain/blob/f2d1ba2c9d713b2aa6e7063f6d11dd3d64aa402a/toolchain/cc_toolchain_config.bzl.tpl#L527-L537) and [Framework paths](https://github.com/grailbio/bazel-toolchain/blob/f2d1ba2c9d713b2aa6e7063f6d11dd3d64aa402a/toolchain/cc_toolchain_config.bzl.tpl#L347-L365) ([only used on macOS](https://github.com/grailbio/bazel-toolchain/blob/f2d1ba2c9d713b2aa6e7063f6d11dd3d64aa402a/toolchain/cc_toolchain_config.bzl.tpl#L498-L499)) are not yet supported; see in-code comments (beginning ## NOTE:). 3. `llvm-strip` is now used for llvm versions ≥7 as the strip binary. 4. Contains fixes for using/running the toolchain from other locations in the execroot. Most notably, `rules_foreign_cc` will use a different PWD than the execroot root for cmake targets which breaks the wrapper script. This commit has the wrapper script search alongside itself for `clang` when it isn't in the usual places. 5. Modern versions of ld.lld support start and end groups but we don't use ld.lld on macOS (yet), so don't use this feature.
I may be missing something but other toolchains seem to support thin_lto or other forms of LTO (https://github.com/tensorflow/tensorflow/blob/1843f39c11e42751837c62acfb74e1fe697353ef/third_party/toolchains/clang6/CROSSTOOL.tpl#L402 for example) -- it would be lovely to support that here. Or perhaps I'm mistaken: can someone suggest how I might enable LTO/pgo in general?
The text was updated successfully, but these errors were encountered: