# Proposal: Add "cargo:rustc-compile-crate-without-waiting-for-build-rs" for build.rs **URL:** \ **Category:** compiler\ **Created:** [August 28, 2022, 3:03pm UTC](https://internals.rust-lang.org/t/proposal-add-cargo-rustc-compile-crate-without-waiting-for-build-rs-for-build-rs/17285 "2022-08-28T15:03:05Z")\ **Posts on this page:** 1\ **Showing post:** 10
**Author:** ![nacaclanga](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nacaclanga/32/7461_2.png) [@nacaclanga](https://internals.rust-lang.org/u/nacaclanga)\ **Post date:** [August 29, 2022, 11:20am UTC](https://internals.rust-lang.org/t/proposal-add-cargo-rustc-compile-crate-without-waiting-for-build-rs-for-build-rs/17285/10 "2022-08-29T11:20:22Z")
I have the feeling that build scripts do two different things: a) Compile and link libraries. b) Generate Rust code While build scripts serve the secound application quite well, they have many shortcomings for the first one in particular: i) Build scripts are compiled and executed, even in check mode. ii) Build scripts poorly interact with each other or with external build systems of any kind. iii) They often requiere options that need to be bubbled up through their users. (E.g. dynamic vs static linkage). Rather them just introducing this flag, it would probably be usefull to introduce a more general way to indicate that something is used to provide some external dependency. My personal suggestion would be a different cargo-packge type (possibly embeddable into an other package) declaring what dependency and version it does provide and what linkage options (static, dynamic, etc), are supported. External dependencies could then be listed (usefull for something like cargo-deb), build in parallel to other code without ever becoming part of any .rlib and being linked into the final executable/dylib using explicit link flags set by cargo, configured globally, being replaced by a version build by an external build system, etc. Edit: See also: > [@Statically-linked C/C++ libraries](https://internals.rust-lang.org/t/statically-linked-c-c-libraries/17175): > > The goal is to explore the current situation of crates including statically linked C/C++ libraries and to start a discussion about ways to make it easier to import external code in crates in a secure and reliable manner. Overview To get an idea of the extent of this pattern, let's explore [crates.io](http://crates.io) content with an analysis of the crates with more than 100k downloads on 2022-08-07 (the 4,7k top crates, see the [methodology](https://github.com/amousset/source-crates/blob/main/methodology.md) for more details). There are currently 70 C/C++ native libraries included… --- _[View the full topic](https://internals.rust-lang.org/t/proposal-add-cargo-rustc-compile-crate-without-waiting-for-build-rs-for-build-rs/17285)._