Skip to content
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

Mark experimental benchmark features manual-only #1

Merged
merged 1 commit into from
Mar 18, 2016

Conversation

kchodorow
Copy link
Contributor

@davidzchen
Copy link
Member

LGTM

kchodorow added a commit that referenced this pull request Mar 18, 2016
Mark experimental benchmark features manual-only
@kchodorow kchodorow merged commit ec1fa21 into bazelbuild:master Mar 18, 2016
SirVer pushed a commit to SirVer/rules_rust that referenced this pull request Mar 26, 2018
)

* Make rule tests compatible with the new string representations in Skylark (bazelbuild#51)

* Rename set to depset (bazelbuild#50)

* Update rules_rust to use Bazel's toolchains feature. (bazelbuild#52)

This allows rust targets to only depend on (and thus download) the
toolchains that are used, dynamically chosen based on the current target
platform.

Fixes bazelbuild#14.

* Sketch of dylib support

* Update compiler toolchain to 1.20.0. (bazelbuild#56)

* Fix transitive dylib support.

* Fix 'data' field not being made available to rust_test rule.

* Topological sort for dylib link flags

* Tidy rpath fn

* Fix linking transitive static libs, and dylib ordering.

* Actually export rust_library.dynamic_libs

* Make sure TMPDIR exists for rustc.

* Properly include dynamic_libs in runfiles.

* fix syntax errors

* more

* Add support for depending on shared libraries on linux.

* Merge raze patches into dylibs branch.

* Fixup merge, including remove broken ctx.file.out_dir_tar from doc_* rules.

* look for native deps when only transitive

* deduplicate rpaths

* hackily fix .so symlink..
dae added a commit to ankitects/rules_rust that referenced this pull request Mar 30, 2021
bazelbuild#1: Include details such as the target architecture in the cache folder
hash. Previously only the path to rustc and the compilation mode was
used to calculate the hash, and this was likely the cause of ICEs.
We now include all of the env vars passed into the request in the hash,
so that separate folders are created for different crate names, crate
versions, and target architectures.

bazelbuild#2: A new worker was previously being created for every rustc invocation,
because the env parameter contained crate-specific details that caused
WorkerKey to change each time. Instead of passing the environment in
directly, persist it to a file, and pass it to process-wrapper with
--env-file instead. We also use the contents of this file in order
to generate the hash mentioned above.

This will mean you'll be limited to 4 workers by default; you may
want to also pass in --worker_max_instances=Rustc=HOST_CPUS*0.5 or
similar, as JIT startup is not a concern for the Rust workers, and
parts of rustc's compilation process are unable to take advantage of
more than 1 CPU core.

bazelbuild#3: Instead of storing incremental files in $TEMP, the worker
is now enabled by providing it with a folder that it should store its
incremental files in, such as:

bazel build --@rules_rust//worker:cache_root=/path/to/cache/files

This mimics the behaviour of --disk_cache and --repository_cache, and
makes it clear where the files are being persisted to.
illicitonion pushed a commit that referenced this pull request Nov 21, 2023
The generated content uses ${pwd} and in the rust-analyzer server output
I see error logs saying can't find dir with ${pwd} references

Though I'm not sure if this actually affect anything as it seems work
fine most of the time, but I think it maybe good to not have
rust-analyzer errors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants