Summary:
A future diff will unify all config loading into configparser::hg, but
to do so we need dynamicconfig to live in configparser, so it can load
dynamicconfigs. Let's move everything in.
Reviewed By: quark-zju
Differential Revision: D22587237
fbshipit-source-id: 5613094175b6e1597aa113ee3e6d92ce7ec79f6d
Summary:
CMake description of `JOB_POOL` is:
"A pool is a named integer property and defines the maximum number of
concurrent jobs which can be started by a rule assigned to the pool."
Not very clear by it looks like putting all the Rust jobs in it prevent CMake
from spawning concurrent jobs when these are running. This should help in
reducing the strain on the system while compiling, while not increasing
compile time.
Reviewed By: wez
Differential Revision: D21595135
fbshipit-source-id: e718c92a237274a9edbc35417644a46bdfde5617
Summary:
When using our vendored set of crates, cmake doesn't
have any dependency information to use to invalidate the Cargo.lock
file when we update crate versions. In addition, since we're
vendoring from a local directory, cargo itself doesn't seem to
want to re-assess the dependencies in that same situation, leading
to confusing error messages like this when we want to build rust
targets:
```
error: failed to select a version for the requirement `anyhow = "= 1.0.26"`
candidate versions found which didn't match: 1.0.28
```
This commit addresses this issue by removing the `Cargo.lock` that
may be alongside the `Cargo.toml` prior to invoking `cargo`.
`cargo` is pretty quick at recomputing the deps so this has
neglible overhead.
Reviewed By: xavierd
Differential Revision: D21394363
fbshipit-source-id: 547db2e2395a47aed77d9597e659eb2d96e274dd
Summary: Actually use vendored Rust crates when building with CMake. The `--offline` option make sure cargo do not go to the Internet for missing crates.
Reviewed By: simpkins
Differential Revision: D20542672
fbshipit-source-id: ab4af40150c6af8b531a75f503a4fa848b3914da
Summary: All the crates are present in third-party/rust, let's use it in the OSS build instead of fetching a tarball of all the crates.
Reviewed By: fanzeyi
Differential Revision: D19770783
fbshipit-source-id: f0d74bb0807be207d599d4868f907d38099c7f5b
Summary:
We've had a small proportion of our users run into problems
with hdiutil and diskimages-helper, where those components get into
an unhappy state and effectively block operating on the redirections.
This diff introduces a new utility that is intended to replace the
use of disk image files with APFS volumes that we mount in the
appropriate places.
The intention is that we will teach `eden redirect` to use this tool
when available, rather than disk images.
macOS's security model is weird: it is perfectly valid for a non-privileged
user to create and delete APFS volumes in the APFS storage container,
but root privs are required to mount it into the VFS.
The intent is that we deploy this utility setuid root to minimize
the fan out--this way we won't need to teach the priv helper about
this kind of redirection.
There are a couple of subcommands demonstrated in the test plan.
Reviewed By: chadaustin
Differential Revision: D19323850
fbshipit-source-id: 35556f841e49e5c4b77679b756af9093222f4500
Summary:
The Rust vendored crates script also depends on another script and the
lfs-pointers file which specifies the ID to use for the download.
Update the RustStaticLibrary.cmake file to make sure that the vendored crates
are re-downloaded if either of these files change.
Reviewed By: wez
Differential Revision: D18846757
fbshipit-source-id: dd67d8d954a048501f0bdaddbd78147d39a1da5f
Summary:
Remove the standalone fb-mercurial-rust target that was an internal-only
dependency for the Eden build. This build step is now done entirely in the
Eden build.
Reviewed By: fanzeyi
Differential Revision: D18623943
fbshipit-source-id: c62a1155ddd1c0a6b2270c472176ba25194c6145
