martinvonz/jj
1
1
Fork 0
mirror of https://github.com/martinvonz/jj.git synced 2024-09-21 02:38:46 +03:00
Code Issues Packages Projects Releases Wiki Activity
36674e8f7e
jj/lib/Cargo.toml

71 lines
1.9 KiB
TOML
Raw Normal View History

import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 11:00:42 +03: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 17:12:40 +03:00
name = "jj-lib"
cargo: unify a lot of crate metadata in the workspace Summary: There's no need to go around specifying `rust-version` or `edition` or `version` several times, now that we have a global workspace. Instead, inherit workspace metadata from the top-level Cargo.toml file. Signed-off-by: Austin Seipp <aseipp@pobox.com> Change-Id: Iaf905445978ed2b3377239dcdb8a6c32
2023-08-06 01:14:11 +03:00
description = "Library for Jujutsu - an experimental version control system"
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 11:00:42 +03:00
Use `{ workspace = true }` to appease VS Code's `Cargo.toml` parser The VS Code "Better TOML" plugin (which I think most of our VS Code developers use?) doesn't support the `x.y = z` syntax at the top level, even though it's valid TOML. This is also useful if we ever want to add additional properties in different sub-crates (although unlikely for the near future).
2023-08-22 19:41:42 +03:00
version = { workspace = true }
edition = { workspace = true }
rust-version = { workspace = true }
license = { workspace = true }
homepage = { workspace = true }
repository = { workspace = true }
documentation = { workspace = true }
readme = { workspace = true }
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 11:00:42 +03:00
benches: move diff_bench to lib crate It has no dependency on the cli crate.
2023-03-27 11:23:27 +03: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 10:12:18 +03:00
[build-dependencies]
Use `{ workspace = true }` to appease VS Code's `Cargo.toml` parser The VS Code "Better TOML" plugin (which I think most of our VS Code developers use?) doesn't support the `x.y = z` syntax at the top level, even though it's valid TOML. This is also useful if we ever want to add additional properties in different sub-crates (although unlikely for the near future).
2023-08-22 19:41:42 +03:00
version_check = { workspace = true }
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 11:00:42 +03:00
[dependencies]
Use `{ workspace = true }` to appease VS Code's `Cargo.toml` parser The VS Code "Better TOML" plugin (which I think most of our VS Code developers use?) doesn't support the `x.y = z` syntax at the top level, even though it's valid TOML. This is also useful if we ever want to add additional properties in different sub-crates (although unlikely for the near future).
2023-08-22 19:41:42 +03:00
backoff = { workspace = true }
blake2 = { workspace = true }
byteorder = { workspace = true }
bytes = { workspace = true }
chrono = { workspace = true }
config = { workspace = true }
digest = { workspace = true }
either = { 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 = { workspace = true }
serde_json = { workspace = true }
smallvec = { workspace = true }
strsim = { workspace = true }
tempfile = { workspace = true }
thiserror = { workspace = true }
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 19:14:11 +03:00
tokio = { workspace = true, optional = true }
Use `{ workspace = true }` to appease VS Code's `Cargo.toml` parser The VS Code "Better TOML" plugin (which I think most of our VS Code developers use?) doesn't support the `x.y = z` syntax at the top level, even though it's valid TOML. This is also useful if we ever want to add additional properties in different sub-crates (although unlikely for the near future).
2023-08-22 19:41:42 +03:00
tracing = { workspace = true }
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 19:14:11 +03:00
watchman_client = { workspace = true, optional = true }
Use `{ workspace = true }` to appease VS Code's `Cargo.toml` parser The VS Code "Better TOML" plugin (which I think most of our VS Code developers use?) doesn't support the `x.y = z` syntax at the top level, even though it's valid TOML. This is also useful if we ever want to add additional properties in different sub-crates (although unlikely for the near future).
2023-08-22 19:41:42 +03:00
whoami = { workspace = true }
zstd = { workspace = true }
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 11:00:42 +03: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 04:54:33 +03:00
[target.'cfg(unix)'.dependencies]
Use `{ workspace = true }` to appease VS Code's `Cargo.toml` parser The VS Code "Better TOML" plugin (which I think most of our VS Code developers use?) doesn't support the `x.y = z` syntax at the top level, even though it's valid TOML. This is also useful if we ever want to add additional properties in different sub-crates (although unlikely for the near future).
2023-08-22 19:41:42 +03: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 04:54:33 +03:00
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 11:00:42 +03:00
[dev-dependencies]
Use `{ workspace = true }` to appease VS Code's `Cargo.toml` parser The VS Code "Better TOML" plugin (which I think most of our VS Code developers use?) doesn't support the `x.y = z` syntax at the top level, even though it's valid TOML. This is also useful if we ever want to add additional properties in different sub-crates (although unlikely for the near future).
2023-08-22 19:41:42 +03:00
assert_matches = { workspace = true }
criterion = { workspace = true }
esl01-renderdag = { workspace = true }
insta = { workspace = true }
num_cpus = { workspace = true }
merged_tree: add diff iterator If we're going to be able to replace most instances of `Tree` by `MergedTree`, we'll need to be able to diff two `MergedTree`s. This implements support for that. The implementation copies a lot from the diff iterator we have for `Tree`. I suspect we should be able to reuse some of the code by introducing some traits that can then be implemented by both `Tree` and `MergedTree`. I've left a TODO about that.
2023-07-06 09:03:55 +03:00
pretty_assertions = { workspace = true }
Use `{ workspace = true }` to appease VS Code's `Cargo.toml` parser The VS Code "Better TOML" plugin (which I think most of our VS Code developers use?) doesn't support the `x.y = z` syntax at the top level, even though it's valid TOML. This is also useful if we ever want to add additional properties in different sub-crates (although unlikely for the near future).
2023-08-22 19:41:42 +03:00
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 10:03:44 +03:00
[features]
op_store: drop support for upgrading from Thrift implementation
2023-03-29 21:13:28 +03: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 10:03:44 +03:00
vendored-openssl = ["git2/vendored-openssl"]
feat(fsmonitor): Watchman filesystem monitor implementation
2023-07-08 12:23:32 +03:00
watchman = ["dep:tokio", "dep:watchman_client"]
Reference in New Issue Copy Permalink