rust/src/librustc/Cargo.toml

[package]
authors = ["The Rust Project Developers"]
name = "rustc"
version = "0.0.0"

[lib]
name = "rustc"
path = "lib.rs"
crate-type = ["dylib"]

[dependencies]
arena = { path = "../libarena" }
bitflags = "1.0"
fmt_macros = { path = "../libfmt_macros" }
graphviz = { path = "../libgraphviz" }
jobserver = "0.1"
log = "0.3"
owning_ref = "0.3.3"
rustc_back = { path = "../librustc_back" }
rustc_const_math = { path = "../librustc_const_math" }
rustc_data_structures = { path = "../librustc_data_structures" }
rustc_errors = { path = "../librustc_errors" }
serialize = { path = "../libserialize" }
syntax = { path = "../libsyntax" }
syntax_pos = { path = "../libsyntax_pos" }

# Note that these dependencies are a lie, they're just here to get linkage to
# work.
#
# We're creating a bunch of dylibs for the compiler but we're also compiling a
# bunch of crates.io crates. Everything in the compiler is compiled as an
# rlib/dylib pair but all crates.io crates tend to just be rlibs. This means
# we've got a problem for dependency graphs that look like:
#
#           foo - rustc_trans
#         /                  \
#   rustc                     ---- rustc_driver
#         \                     /
#           foo - rustc_metadata
#
# Here the crate `foo` is linked into the `rustc_trans` and the
# `rustc_metadata` dylibs, meaning we've got duplicate copies! When we then
# go to link `rustc_driver` the compiler notices this and gives us a compiler
# error.
#
# To work around this problem we just add these crates.io dependencies to the
# `rustc` crate which is a shared dependency above. That way the crate `foo`
# shows up in the dylib for the `rustc` crate, deduplicating it and allowing
# crates like `rustc_trans` to use `foo` *through* the `rustc` crate.
#
# tl;dr; this is not needed to get `rustc` to compile, but if you remove it then
#        later crate stop compiling. If you can remove this and everything
#        compiles, then please feel free to do so!
flate2 = "0.2"
bootstrap: Add a bunch of Cargo.toml files These describe the structure of all our crate dependencies. 2016-01-21 17:19:23 -06:00			`[package]`
			`authors = ["The Rust Project Developers"]`
			`name = "rustc"`
			`version = "0.0.0"`

			`[lib]`
			`name = "rustc"`
			`path = "lib.rs"`
			`crate-type = ["dylib"]`

			`[dependencies]`
			`arena = { path = "../libarena" }`
Remove rustc_bitflags; use the bitflags crate 2017-09-08 14:08:01 -05:00			`bitflags = "1.0"`
bootstrap: Add a bunch of Cargo.toml files These describe the structure of all our crate dependencies. 2016-01-21 17:19:23 -06:00			`fmt_macros = { path = "../libfmt_macros" }`
			`graphviz = { path = "../libgraphviz" }`
Integrate jobserver support to parallel codegen This commit integrates the `jobserver` crate into the compiler. The crate was previously integrated in to Cargo as part of rust-lang/cargo#4110. The purpose here is to two-fold: * Primarily the compiler can cooperate with Cargo on parallelism. When you run `cargo build -j4` then this'll make sure that the entire build process between Cargo/rustc won't use more than 4 cores, whereas today you'd get 4 rustc instances which may all try to spawn lots of threads. * Secondarily rustc/Cargo can now integrate with a foreign GNU `make` jobserver. This means that if you call cargo/rustc from `make` or another jobserver-compatible implementation it'll use foreign parallelism settings instead of creating new ones locally. As the number of parallel codegen instances in the compiler continues to grow over time with the advent of incremental compilation it's expected that this'll become more of a problem, so this is intended to nip concurrent concerns in the bud by having all the tools to cooperate! Note that while rustc has support for itself creating a jobserver it's far more likely that rustc will always use the jobserver configured by Cargo. Cargo today will now set a jobserver unconditionally for rustc to use. 2017-06-15 09:08:18 -05:00			`jobserver = "0.1"`
Remove internal liblog This commit deletes the internal liblog in favor of the implementation that lives on crates.io. Similarly it's also setting a convention for adding crates to the compiler. The main restriction right now is that we want compiler implementation details to be unreachable from normal Rust code (e.g. requires a feature), and by default everything in the sysroot is reachable via `extern crate`. The proposal here is to require that crates pulled in have these lines in their `src/lib.rs`: #![cfg_attr(rustbuild, feature(staged_api, rustc_private))] #![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))] This'll mean that by default they're not using these attributes but when compiled as part of the compiler they do a few things: * Mark themselves as entirely unstable via the `staged_api` feature and the `#![unstable]` attribute. * Allow usage of other unstable crates via `feature(rustc_private)` which is required if the crate relies on any other crates to compile (other than std). 2017-02-15 09:57:59 -06:00			`log = "0.3"`
Remove rustc_llvm dependency from rustc_metadata Move the code for loading metadata from rlibs and dylibs from rustc_metadata into rustc_trans, and introduce a trait to avoid introducing a direct dependency on rustc_trans. This means rustc_metadata is no longer rebuilt when LLVM changes. 2017-04-26 16:22:45 -05:00			`owning_ref = "0.3.3"`
bootstrap: Add a bunch of Cargo.toml files These describe the structure of all our crate dependencies. 2016-01-21 17:19:23 -06:00			`rustc_back = { path = "../librustc_back" }`
rename `rustc_const_eval` to `rustc_const_math` 2016-03-15 06:33:13 -05:00			`rustc_const_math = { path = "../librustc_const_math" }`
bootstrap: Add a bunch of Cargo.toml files These describe the structure of all our crate dependencies. 2016-01-21 17:19:23 -06:00			`rustc_data_structures = { path = "../librustc_data_structures" }`
Move errors from libsyntax to its own crate 2016-06-21 17:08:13 -05:00			`rustc_errors = { path = "../librustc_errors" }`
bootstrap: Add a bunch of Cargo.toml files These describe the structure of all our crate dependencies. 2016-01-21 17:19:23 -06:00			`serialize = { path = "../libserialize" }`
			`syntax = { path = "../libsyntax" }`
Fix `Cargo.toml`s 2016-06-27 12:45:33 -05:00			`syntax_pos = { path = "../libsyntax_pos" }`
Remove the in-tree `flate` crate A long time coming this commit removes the `flate` crate in favor of the `flate2` crate on crates.io. The functionality in `flate2` originally flowered out of `flate` itself and is additionally the namesake for the crate. This will leave a gap in the naming (there's not `flate` crate), which will likely cause a particle collapse of some form somewhere. 2017-06-08 16:10:36 -05:00
			`# Note that these dependencies are a lie, they're just here to get linkage to`
			`# work.`
			`#`
			`# We're creating a bunch of dylibs for the compiler but we're also compiling a`
			`# bunch of crates.io crates. Everything in the compiler is compiled as an`
			`# rlib/dylib pair but all crates.io crates tend to just be rlibs. This means`
			`# we've got a problem for dependency graphs that look like:`
			`#`
			`# foo - rustc_trans`
			`# / \`
			`# rustc ---- rustc_driver`
			`# \ /`
			`# foo - rustc_metadata`
			`#`
			# Here the crate `foo` is linked into the `rustc_trans` and the
			# `rustc_metadata` dylibs, meaning we've got duplicate copies! When we then
			# go to link `rustc_driver` the compiler notices this and gives us a compiler
			`# error.`
			`#`
			`# To work around this problem we just add these crates.io dependencies to the`
			# `rustc` crate which is a shared dependency above. That way the crate `foo`
			# shows up in the dylib for the `rustc` crate, deduplicating it and allowing
			# crates like `rustc_trans` to use `foo` through the `rustc` crate.
			`#`
			# tl;dr; this is not needed to get `rustc` to compile, but if you remove it then
			`# later crate stop compiling. If you can remove this and everything`
			`# compiles, then please feel free to do so!`
			`flate2 = "0.2"`