This was meant to avoid using `gold`, but `lld` might not be installed.
Having `gold` installed results in the following warning:
```
warning: the gold linker is deprecated and has known bugs with Rust
|
= help: consider using LLD or ld from GNU binutils instead
```
* if a user sees this warning, they can provide the `lld` or whatever
linker they prefer themselves, or make sure to uninstall `gold`
* in any case, this is not what we use for releasing (where we are sure
we don't use `gold`).
Also:
* remove new warnings raised by the rust toolchain
* run new formatting and linting
* update the rust toolchain used by `cargo`
While we keep `bazel` builds using the same toolchain as internally
(now a nightly one), I opted for using a stable toolchain for `cargo`.
The nightly toolchain is only required internally for build reasons, we
should keep not using any unstable rust features in our sources.
Previously, we were using 8.0.0rc1.
In particular, this upgrade means we need to explicitly
import more rules, as they've been moved out of the core bazel repo.
We've been observing some performance issues using crate_universe on CI.
Therefore, we're moving to vendor the auto-generated BUILD files
in our repository. This should provide a nice speed boost, while
getting rid of the complexity of the "rust cache" job we've been using
when we had a lot of git dependencies.
This PR includes a vendor script, and I'll put up a CI job internally
that runs that vendor script on Cargo.toml and Cargo.lock changes, to check
that the vendored files are in sync.
We've hardcoded the tilde in a lot of places :(
This improves performance on Windows and gets us ready for Bazel 8.
We need an upgrade of rules_rust for this to work.
This should allow us to build our python and ruby
code independently - in particular, we can now do shallow
checkouts of one without the other.
Previously, the modext introduced cross-dependency.
This also reduces the amount of work we do in the
crate universe processing for the other language, even
though it's unused.
This does need renaming the module, as otherwise
the generated paths from rules_rust get too long
for Windows :(
This commits a bazel-based build system for C#
using `rules_dotnet`. External dependencies are managed
via `paket`, and updates to the generated bazel files
are done via `./update-deps.sh`.
We're providing our own (minimal) test runner for `xunit`
tests.
It turns out everything that is needed for the installer to work on
windows is enabling runfiles. This also requires symlinks to avoid
excessive copying of files.
This adds a first dummy extractor for swift.
Running `bazel run //swift:install` will create an `extractor_pack`
directory in `swift`. From that moment providing `--search-path=swift`
will pick up the extractor.
