* `system_module_maps` no longer performs any IO.
* The generated module map no longer references any non-hermetic paths
and can thus be cached remotely, even when toolchain or sysroot are
provided as absolute paths.
Currently the repo rule and tag class accept string-form labels for
toolchain root packages and sysroots. Under `bzlmod` this is problematic
because users may pass us labels that point at repos that are not in
this module's repo mapping. To support such labels, they need to be
passed to us as actual `Label`s (not strings).
This necessitates some (**breaking**) changes to interface for the
module extension tags. The repo rule interface remains the same.
For the "llvm" module extension, two new tags have been introduced:
- `toolchain_root`, and
- `sysroot`
Alternatives considered:
1. Using a `label_keyed_string_dict` would not work if we still want to
support absolute paths in these attributes.
2. Using string aliases instead of string labels, and then a separate
attribute for a side table that maps labels to their aliases could also
work. This would have to be done only for the module extension
and not the repo rule, because specifying labels in repo rules
eagerly fetches them.
I've also enabled bzlmod-enabled tests for the system paths, absolute
paths, and cross tests in CI.
Fixes #234. cc: @steve-261370
---------
Co-authored-by: Siddhartha Bagaria <starsid@gmail.com>
This removes the need to provide flags like:
- `--incompatible_enable_cc_toolchain_resolution`
- `--features=-libtool` on macOS.
- `--features=-supports_dynamic_linker` on macOS.
As part of the update, test dep versions have also been updated.
* Add support for `layering_check`
The general support for this feature is inherited from the
Bazel-provided Unix C++ toolchain, except that a module map for the
toolchain and sysroot headers has to be supplied to the `cc_toolchain`.
Requires an update of abseil-cpp to make it compatible with
`layering_check`. Some other deps also needed to be updated.
Also fixes some nits related to Bazel 7 upgrade.
- Prepare for BCR release as 0.10.0
- Rename repo name to toolchains_llvm
- Upgrade Go version in tests and remove -nopie flag
- Combine lint and tests workflow
This is a fairly straightforward change that adds support for using `bazel-toolchain` with `bzlmod`.
The `llvm.toolchain` extension is only a wrapper around the existing `llvm_toolchain` repository rule and supports the same attributes.
For trying it out, add the following to your `MODULE.bazel`:
```
bazel_dep(name = "com_grail_bazel_toolchain", version = "0.8")
git_override(module_name = "com_grail_bazel_toolchain", remote = "https://github.com/grailbio/bazel-toolchain", commit = "cf915e5c7cfcd19a3e71de54e385e01240b865dc")
llvm = use_extension("@com_grail_bazel_toolchain//toolchain:extensions.bzl", "llvm")
llvm.toolchain(
llvm_version = "15.0.0"
)
use_repo(llvm, "llvm_toolchain")
register_toolchains("@llvm_toolchain//:all")
```
---------
Co-authored-by: James Sharpe <james.sharpe@zenotech.com>
Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>
Co-authored-by: Gabriel Féron <g@leirbagl.net>
The `llvm_versions` attr is currently not being used to auto-detect toolchains
and is only used for the `urls` and `toolchain_roots` attributes.
Users who want to simply specify different LLVM versions for different host
OS/arch currently also need to specify the `urls` attribute even when the
auto-detection logic would otherwise be sufficient (see default toolchain in
tests/WORKSPACE).
With this change, the `urls` and associated `strip_prefix` and `sha256`
attributes will be unnecessary. The default toolchain in `tests/WORKSPACE`
has also been changed to reflect this.
---------
Co-authored-by: Siddhartha Bagaria <sidb@x.team>
These tests have not been useful for many past bazel versions, and
mostly not reliable. As bazel has become more stable, we expect
migration issues to be fewer. We do run tests with our minimum supported
bazel version and with the latest version of bazel. So a breakage with a
new release of bazel will be caught.
Code was not very clear in how system paths were being handled after the
last refactoring. Now cleaned up the code and some variable names to
read better, and added a unit test in CI.
Fixes #162.
Current strategy for detecting OS name and matching it to an LLVM
distribution archive has many corner cases. Moreover, people might have
their own URLs where they host these archives.
Having an explicit dict of URLs and sha256, keyed by OS name, version
and arch, will help people get over these corner cases, and be able to
try new LLVM releases without waiting for an update to this repository.
Note that the keys here are different than the `toolchain_roots`
attribute.
While this method does have an extra setup step for each new OS type
that the user's workspace needs to support, this approach is more
flexible.
If we notice that people are using this feature more than the
auto inferred URLs, or that the llvm_release_names.py script is out of
date, we may just retain this feature, and delete the other way of
getting archives.
Additionally, fixes #125. People with that use case can now use the
`urls` attribute, or use the new convenience aliases.
Make separate the notion of host and target OS and CPU architecture
throughout the codebase.
Always take {os}-{arch} pairs where we were taking just the os name
before and be clear when it is intended to be host and when target.
Separating the distribution from the configuration will allow users to
bring the distribution in other forms, like through `local_repository`.
It will also make it such that the LLVM distribution does not have to
be downloaded and extracted for toolchain registration during
workspace initialization.
Fixes #40.
The toolchain now requires `rules_cc` to be defined either manually by
the user, or through `bazel_toolchain_dependencies` before the llvm
toolchain is defined.
Resolves #34.
Fabian Meumertzheim