mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2025-01-13 07:32:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
jj/lib/Cargo.toml

70 lines
1.7 KiB
TOML
Raw Normal View History

import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
[package]
cargo: rename crates from `jujutsu`/`jujutsu-lib` to `jj-cli`/`jj-lib` Almost everyone calls the project "jj", and there seeems to be consensus that we should rename the crates. I originally wanted the crates to be called `jj` and `jj-lib`, but `jj` was already taken. `jj-cli` is probably at least as good for it anyway. Once we've published a 0.8.0 under the new names, we'll release 0.7.1 versions under the old names with pointers to the new crates names.
2023-06-28 14:12:40 +00:00
name = "jj-lib"
release: release version 0.8.0 Thanks to everyone who's contributed!
2023-07-09 04:41:55 +00:00
version = "0.8.0"
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
authors = ["Martin von Zweigbergk <martinvonz@google.com>"]
cargo: upgrade to Rust 2021 (just to stay up to date)
2021-12-14 05:38:10 +00:00
edition = "2021"
chore(rust): bump MSRV to 1.71.0 Summary: Let's be more aggressive about tracking the latest stable Rust release. There's little benefit to being conservative so early on, especially when no users seem to have faced any issue with upgrading, or strictly required an old Rust version. Right now, just lagging Rust by 1 major release probably seems fine. We're targeting 1.71.0 to get ahead of the curve, since 1.72.0 will likely release sometime before the next `jj` release. Signed-off-by: Austin Seipp <aseipp@pobox.com> Change-Id: I4e691b6ba63b5b9023a75ae0a6917672
2023-07-11 13:08:13 +00:00
rust-version = "1.71"
cargo: fill in crates.io metadata
2021-01-03 16:45:07 +00:00
license = "Apache-2.0"
project: rename project from Jujube to Jujutsu "Jujutsu" is probably much more familiar and relatable to most people. Also, I'm still not sure how "jujube" is supposed to be pronounced :P
2021-05-15 16:16:31 +00:00
description = "Library for Jujutsu (an experimental VCS)"
cargo: fill in crates.io metadata
2021-01-03 16:45:07 +00:00
homepage = "https://github.com/martinvonz/jj"
repository = "https://github.com/martinvonz/jj"
cargo: rename crates from `jujutsu`/`jujutsu-lib` to `jj-cli`/`jj-lib` Almost everyone calls the project "jj", and there seeems to be consensus that we should rename the crates. I originally wanted the crates to be called `jj` and `jj-lib`, but `jj` was already taken. `jj-cli` is probably at least as good for it anyway. Once we've published a 0.8.0 under the new names, we'll release 0.7.1 versions under the old names with pointers to the new crates names.
2023-06-28 14:12:40 +00:00
documentation = "https://docs.rs/jj-lib"
cargo: fill in crates.io metadata
2021-01-03 16:45:07 +00:00
readme = "../README.md"
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
benches: move diff_bench to lib crate It has no dependency on the cli crate.
2023-03-27 08:23:27 +00:00
[[bench]]
name = "diff_bench"
harness = false
protobuf: generate code at build-time I had tried to generate the protobuf code at build time many months ago, but decided against it because it slowed down the build too much. I didn't realize there was the "cargo:rerun-if-changed=<filename>" feature that time. Given that that exists, it seems like an obvious win to generate the source code at build time. I put the generated sources in `$OUT_DIR` (where [1] says they should be), then include them in the `protos` module by using the `include!` macro. The biggest problem with that is that I couldn't get IntelliJ to understand it, even after enabling the experimental features described in [2]. [1] https://doc.rust-lang.org/cargo/reference/build-script-examples.html#code-generation [2] https://github.com/intellij-rust/intellij-rust/issues/1908#issuecomment-592773865
2020-12-24 07:12:18 +00:00
[build-dependencies]
cargo: unify dependency versions through workspace deps Summary: This moves all dependencies across the jj-lib and jj-cli crates into the top-level Cargo file; with that, we can change each crate instead to just inherit the workspace version, with the toggled features enabled, by setting a dependency such as: dep.workspace = true in the relevant Cargo.toml file. This doesn't actually change any of the build semantics (from what I can tell) nor the lockfile, and seems to respond normally. There are more cleanups that can follow. Two notes: - Dependabot seems to work fine, based on what I've seen in other repos. - `cargo add` doesn't seem to know how to add packages to a top-level `workspace.dependencies` field; instead you can `cargo add -p jj-cli` and move the entries, at least. Signed-off-by: Austin Seipp <aseipp@pobox.com> Change-Id: I307827e5f15c0d8ea8e2a80ec793d3c7
2023-08-05 16:14:11 +00:00
version_check.workspace = true
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
[dependencies]
cargo: unify dependency versions through workspace deps Summary: This moves all dependencies across the jj-lib and jj-cli crates into the top-level Cargo file; with that, we can change each crate instead to just inherit the workspace version, with the toggled features enabled, by setting a dependency such as: dep.workspace = true in the relevant Cargo.toml file. This doesn't actually change any of the build semantics (from what I can tell) nor the lockfile, and seems to respond normally. There are more cleanups that can follow. Two notes: - Dependabot seems to work fine, based on what I've seen in other repos. - `cargo add` doesn't seem to know how to add packages to a top-level `workspace.dependencies` field; instead you can `cargo add -p jj-cli` and move the entries, at least. Signed-off-by: Austin Seipp <aseipp@pobox.com> Change-Id: I307827e5f15c0d8ea8e2a80ec793d3c7
2023-08-05 16:14:11 +00:00
backoff.workspace = true
blake2.workspace = true
byteorder.workspace = true
bytes.workspace = true
chrono.workspace = true
config.workspace = true
digest.workspace = true
git2.workspace = true
hex.workspace = true
itertools.workspace = true
maplit.workspace = true
once_cell.workspace = true
pest.workspace = true
pest_derive.workspace = true
prost.workspace = true
rand.workspace = true
rand_chacha.workspace = true
rayon.workspace = true
regex.workspace = true
serde_json.workspace = true
smallvec.workspace = true
strsim.workspace = true
tempfile.workspace = true
thiserror.workspace = true
tokio = { workspace = true, optional = true }
tracing.workspace = true
watchman_client = { workspace = true, optional = true }
whoami.workspace = true
zstd.workspace = true
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
lib: use advisory locks on Unix targets Allows automatic recovery when encountering stale lockfiles, and more efficient blocking rather than polling for fresh ones. The previous implementation is preserved for other platforms.
2023-05-06 01:54:33 +00:00
[target.'cfg(unix)'.dependencies]
cargo: unify dependency versions through workspace deps Summary: This moves all dependencies across the jj-lib and jj-cli crates into the top-level Cargo file; with that, we can change each crate instead to just inherit the workspace version, with the toggled features enabled, by setting a dependency such as: dep.workspace = true in the relevant Cargo.toml file. This doesn't actually change any of the build semantics (from what I can tell) nor the lockfile, and seems to respond normally. There are more cleanups that can follow. Two notes: - Dependabot seems to work fine, based on what I've seen in other repos. - `cargo add` doesn't seem to know how to add packages to a top-level `workspace.dependencies` field; instead you can `cargo add -p jj-cli` and move the entries, at least. Signed-off-by: Austin Seipp <aseipp@pobox.com> Change-Id: I307827e5f15c0d8ea8e2a80ec793d3c7
2023-08-05 16:14:11 +00:00
rustix.workspace = true
lib: use advisory locks on Unix targets Allows automatic recovery when encountering stale lockfiles, and more efficient blocking rather than polling for fresh ones. The previous implementation is preserved for other platforms.
2023-05-06 01:54:33 +00:00
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
[dev-dependencies]
cargo: unify dependency versions through workspace deps Summary: This moves all dependencies across the jj-lib and jj-cli crates into the top-level Cargo file; with that, we can change each crate instead to just inherit the workspace version, with the toggled features enabled, by setting a dependency such as: dep.workspace = true in the relevant Cargo.toml file. This doesn't actually change any of the build semantics (from what I can tell) nor the lockfile, and seems to respond normally. There are more cleanups that can follow. Two notes: - Dependabot seems to work fine, based on what I've seen in other repos. - `cargo add` doesn't seem to know how to add packages to a top-level `workspace.dependencies` field; instead you can `cargo add -p jj-cli` and move the entries, at least. Signed-off-by: Austin Seipp <aseipp@pobox.com> Change-Id: I307827e5f15c0d8ea8e2a80ec793d3c7
2023-08-05 16:14:11 +00:00
assert_matches.workspace = true
criterion.workspace = true
esl01-renderdag.workspace = true
insta.workspace = true
num_cpus.workspace = true
test-case.workspace = true
testutils.workspace = true
cargo: use libgit2 with vendored OpenSSL (#73) I was able to build a working musl binary with this change, by running this command: ``` cargo build --release --target x86_64-unknown-linux-musl ``` Thanks to @arxanas for the tip.
2022-03-13 07:03:44 +00:00
[features]
op_store: drop support for upgrading from Thrift implementation
2023-03-29 18:13:28 +00:00
default = []
cargo: use libgit2 with vendored OpenSSL (#73) I was able to build a working musl binary with this change, by running this command: ``` cargo build --release --target x86_64-unknown-linux-musl ``` Thanks to @arxanas for the tip.
2022-03-13 07:03:44 +00:00
vendored-openssl = ["git2/vendored-openssl"]
feat(fsmonitor): Watchman filesystem monitor implementation
2023-07-08 09:23:32 +00:00
watchman = ["dep:tokio", "dep:watchman_client"]
Reference in a new issue Copy permalink