88520e6858
Large workspaces end up with a very large number of possible build configurations. Even worse, the feature set of a package affects everything that depends on it, so syn being built with a slightly different feature set than before would cause *every package that directly or transitively depends on syn to be rebuilt. For large workspaces, this can result a lot of wasted build time. To avoid this problem, many large workspaces contain a workspace-hack crate. The purpose of this package is to ensure that dependencies like syn are always built with the same feature set no matter which workspace packages are currently being built. This is done by: 1) adding dependencies like syn to workspace-hack with the full feature set required by any package in the workspace 2) adding workspace-hack as a dependency of every crate in the repository. cargo-hakari manages a workspace-hack crate for you.
55 lines
2.2 KiB
TOML
55 lines
2.2 KiB
TOML
[package]
|
|
name = "starmelon"
|
|
version = "0.1.0"
|
|
edition = "2018"
|
|
|
|
# I decided to use os_pipe becaues I want to pipe stdout of a subprocess into
|
|
# stderr in real time. I want the output of the process to stderr and stdout
|
|
# show up in the original order. I looked an os_pipe uses some unsafe code to
|
|
# duplicate file descriptors. I am unfamiliar with the correct way of sharing
|
|
# the fds. Therefore I am going to trust that their unsafe code is necessary.
|
|
# Then it makes sense to use a battle tested unsafe code rather than implement
|
|
# it myself.
|
|
[dependencies]
|
|
ahash = "0.7"
|
|
elmi = { path = "../../../infra/rust-elmi", features = [ "genco" ] }
|
|
naive-wadler-prettier= { path = "../../../infra/redwood-lang/compiler/naive-wadler-prettier" }
|
|
os_pipe = "0.9"
|
|
serde = { version = "1.0", features = [ "derive" ] }
|
|
serde_json = { version ="1.0", features = [] }
|
|
structopt = { version = "0.3" }
|
|
elm-project-utils = { path = "../../../infra/rust-elm-project-utils" }
|
|
tracing = { version = "0.1", features = [] }
|
|
rustc-hash = "1.1"
|
|
home = "0.5"
|
|
|
|
# Required to transpile view functions to Rust
|
|
genco = "0.15"
|
|
# Required to generate fixture Elm files
|
|
genco-extra = { path = "../../../infra/genco-extra" }
|
|
|
|
|
|
# All of these are required for deno's javascript runtime. We need to keep the
|
|
# same versions as other projects in our cargo workspace. Multiple different
|
|
# versions of rust_v8 seem to break its build script.
|
|
deno_runtime = "0.50"
|
|
tokio = { version = "1.17", features = ["full"] }
|
|
deno_core = "0.124"
|
|
deno_web = "0.73"
|
|
futures = "0.3"
|
|
|
|
# Required to add sql query support to interpreter. Because deno expects sync
|
|
# ops to be synchronous, we have to use a second async executor to run the sqlx
|
|
# functions. I read the code for oneshot
|
|
# (https://github.com/faern/oneshot/commit/9aa237f185e1b65d61bf92c20350cf7bee0aa88b)
|
|
# and it looks reasonable.
|
|
sqlx = { version = "0.5", features = [ "sqlite", "macros", "runtime-tokio-rustls", "chrono", "json", "uuid" ] }
|
|
oneshot = "0.1.3"
|
|
|
|
# required for livetable derive macro
|
|
livetable-core = { path = "../../../infra/livetable/core" }
|
|
cargo-workspace-hack = { version = "0.1", path = "../../../infra/cargo-workspace-hack" }
|
|
|
|
|
|
[dev-dependencies]
|
|
aho-corasick = "0.7"
|