mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
c746be2219
rust/compiler/rustc/Cargo.toml

26 lines
661 B
TOML
Raw Normal View History

Add a Cargo-based build system This commit is the start of a series of commits which start to replace the makefiles with a Cargo-based build system. The aim is not to remove the makefiles entirely just yet but rather just replace the portions that invoke the compiler to do the bootstrap. This commit specifically adds enough support to perform the bootstrap (and all the cross compilation within) along with generating documentation. More commits will follow up in this series to actually wire up the makefiles to call this build system, so stay tuned!
2015-11-19 17:20:12 -06:00
[package]
name = "rustc-main"
version = "0.0.0"
Migrate to 2021
2021-09-19 11:49:55 -05:00
edition = "2021"
Add a Cargo-based build system This commit is the start of a series of commits which start to replace the makefiles with a Cargo-based build system. The aim is not to remove the makefiles entirely just yet but rather just replace the portions that invoke the compiler to do the bootstrap. This commit specifically adds enough support to perform the bootstrap (and all the cross compilation within) along with generating documentation. More commits will follow up in this series to actually wire up the makefiles to call this build system, so stay tuned!
2015-11-19 17:20:12 -06:00
[dependencies]
mv compiler to compiler/
2020-08-27 22:58:48 -05:00
rustc_driver = { path = "../rustc_driver" }
Use `jemalloc-sys` on Linux and OSX compilers This commit adds opt-in support to the compiler to link to `jemalloc` in the compiler. When activated the compiler will depend on `jemalloc-sys`, instruct jemalloc to unprefix its symbols, and then link to it. The feature is activated by default on Linux/OSX compilers for x86_64/i686 platforms, and it's not enabled anywhere else for now. We may be able to opt-in other platforms in the future! Also note that the opt-in only happens on CI, it's otherwise unconditionally turned off by default. Closes #36963
2018-10-20 21:15:06 -05:00
Move fake rustc_codegen_ssa dependency from rustc_driver to rustc-main
2018-11-19 11:28:44 -06:00
# Make sure rustc_codegen_ssa ends up in the sysroot, because this
# crate is intended to be used by codegen backends, which may not be in-tree.
mv compiler to compiler/
2020-08-27 22:58:48 -05:00
rustc_codegen_ssa = { path = "../rustc_codegen_ssa" }
Move fake rustc_codegen_ssa dependency from rustc_driver to rustc-main
2018-11-19 11:28:44 -06:00
use jemallocator in rustc/rustdoc
2021-04-04 16:07:56 -05:00
[dependencies.tikv-jemalloc-sys]
version = '0.4.0'
rustc: Move jemalloc from rustc_driver to rustc This commit moves jemalloc to just the rustc binary rather than the rustc_driver shared library, enusring that it's only used for binaries that opt-in to it like rustc rather than other binaries using librustc_driver like rustdoc/rls/etc. This will hopefully address #56980
2018-12-19 10:27:23 -06:00
optional = true
features = ['unprefixed_malloc_on_supported_platforms']
use jemallocator in rustc/rustdoc
2021-04-04 16:07:56 -05:00
[dependencies.tikv-jemallocator]
version = '0.4.0'
optional = true
Use `jemalloc-sys` on Linux and OSX compilers This commit adds opt-in support to the compiler to link to `jemalloc` in the compiler. When activated the compiler will depend on `jemalloc-sys`, instruct jemalloc to unprefix its symbols, and then link to it. The feature is activated by default on Linux/OSX compilers for x86_64/i686 platforms, and it's not enabled anywhere else for now. We may be able to opt-in other platforms in the future! Also note that the opt-in only happens on CI, it's otherwise unconditionally turned off by default. Closes #36963
2018-10-20 21:15:06 -05:00
[features]
use jemallocator in rustc/rustdoc
2021-04-04 16:07:56 -05:00
jemalloc = ['tikv-jemalloc-sys', 'tikv-jemallocator']
rustc: Link LLVM directly into rustc again This commit builds on #65501 continue to simplify the build system and compiler now that we no longer have multiple LLVM backends to ship by default. Here this switches the compiler back to what it once was long long ago, which is linking LLVM directly to the compiler rather than dynamically loading it at runtime. The `codegen-backends` directory of the sysroot no longer exists and all relevant support in the build system is removed. Note that `rustc` still supports a dynamically loaded codegen backend as it did previously, it just no longer supports dynamically loaded codegen backends in its own sysroot. Additionally as part of this the `librustc_codegen_llvm` crate now once again explicitly depends on all of its crates instead of implicitly loading them through the sysroot. This involved filling out its `Cargo.toml` and deleting all the now-unnecessary `extern crate` annotations in the header of the crate. (this in turn required adding a number of imports for names of macros too). The end results of this change are: * Rustbuild's build process for the compiler as all the "oh don't forget the codegen backend" checks can be easily removed. * Building `rustc_codegen_llvm` is much simpler since it's simply another compiler crate. * Managing the dependencies of `rustc_codegen_llvm` is much simpler since it's "just another `Cargo.toml` to edit" * The build process should be a smidge faster because there's more parallelism in the main rustc build step rather than splitting `librustc_codegen_llvm` out to its own step. * The compiler is expected to be slightly faster by default because the codegen backend does not need to be dynamically loaded. * Disabling LLVM as part of rustbuild is still supported, supporting multiple codegen backends is still supported, and dynamic loading of a codegen backend is still supported.
2019-10-22 10:51:35 -05:00
llvm = ['rustc_driver/llvm']
just max_level_info
2020-09-11 11:37:51 -05:00
max_level_info = ['rustc_driver/max_level_info']
Reference in New Issue Copy Permalink