mirror of
https://github.com/neondatabase/neon.git
synced 2026-01-13 16:32:56 +00:00
df5a55c445
Our builds can be a little inconsistent, because Cargo doesn't deal well with workspaces where there are multiple crates which have different dependencies that select different features. As a workaround, copy what other big rust projects do: add a workspace_hack crate. This crate just pins down a set of dependencies and features that satisfies all of the workspace crates. The benefits are: - running `cargo build` from one of the workspace subdirectories now works without rebuilding anything. - running `cargo install` works (without rebuilding anything). - making small dependency changes is much less likely to trigger large dependency rebuilds.
24 lines
1.1 KiB
XML
24 lines
1.1 KiB
XML
//! This crate contains no code.
|
|
//!
|
|
//! The workspace_hack crate exists only to pin down some dependencies,
|
|
//! so that those dependencies always build with the same features,
|
|
//! under a few different cases that can be problematic:
|
|
//! - Running `cargo check` or `cargo build` from a crate sub-directory
|
|
//! instead of the workspace root.
|
|
//! - Running `cargo install`, which can only be done per-crate
|
|
//!
|
|
//! The dependency lists in Cargo.toml were automatically generated by
|
|
//! a tool called
|
|
//! [Hakari](https://github.com/facebookincubator/cargo-guppy/tree/main/tools/hakari).
|
|
//!
|
|
//! Hakari doesn't have a CLI yet; in the meantime the example code in
|
|
//! their `README` file is enough to regenerate the dependencies.
|
|
//! Hakari's output was pasted into Cargo.toml, except for the
|
|
//! following manual edits:
|
|
//! - `winapi` dependency was removed. This is probably just due to the
|
|
//! fact that Hakari's target analysis is incomplete.
|
|
//!
|
|
//! There isn't any penalty to this data falling out of date; it just
|
|
//! means that under the conditions above Cargo will rebuild more
|
|
//! packages than strictly necessary.
|