mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
a820d99eb2
rust/mk/crates.mk

232 lines
9.3 KiB
Makefile
Raw Normal View History

Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
# Copyright 2014 The Rust Project Developers. See the COPYRIGHT
# file at the top-level directory of this distribution and at
# http://rust-lang.org/COPYRIGHT.
#
# Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
# http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
# <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
# option. This file may not be copied, modified, or distributed
# except according to those terms.
################################################################################
# Rust's standard distribution of crates and tools
#
# The crates outlined below are the standard distribution of libraries provided
# in a rust installation. These rules are meant to abstract over the
# dependencies (both native and rust) of crates and basically generate all the
# necessary makefile rules necessary to build everything.
#
# Here's an explanation of the variables below
#
# TARGET_CRATES
# This list of crates will be built for all targets, including
# cross-compiled targets
#
# HOST_CRATES
# This list of crates will be compiled for only host targets. Note that
# this set is explicitly *not* a subset of TARGET_CRATES, but rather it is
# a disjoint set. Nothing in the TARGET_CRATES set can depend on crates in
# the HOST_CRATES set, but the HOST_CRATES set can depend on target
# crates.
#
# TOOLS
# A list of all tools which will be built as part of the compilation
# process. It is currently assumed that most tools are built through
# src/driver/driver.rs with a particular configuration (there's a
# corresponding library providing the implementation)
#
# DEPS_<crate>
# These lists are the dependencies of the <crate> that is to be built.
Fallout from libgreen and libnative removal
2014-11-14 16:38:41 -06:00
# Rust dependencies are listed bare (i.e. std) and native
rustdoc: Migrate from sundown to hoedown This primary fix brought on by this upgrade is the proper matching of the ``` and ~~~ doc blocks. This also moves hoedown to a git submodule rather than a bundled repository. Additionally, hoedown is stricter about code blocks, so this ended up fixing a lot of invalid code blocks (ending with " ```" instead of "```", or ending with "~~~~" instead of "~~~"). Closes #12776
2014-05-02 19:56:35 -05:00
# dependencies have a "native:" prefix (i.e. native:hoedown). All deps
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
# will be built before the crate itself is built.
#
# TOOL_DEPS_<tool>/TOOL_SOURCE_<tool>
# Similar to the DEPS variable, this is the library crate dependencies
# list for tool as well as the source file for the specified tool
#
# You shouldn't need to modify much other than these variables. Crates are
# automatically generated for all stage/host/target combinations.
################################################################################
mk: Distribute fewer TARGET_CRATES Right now everything in TARGET_CRATES is built by default for all non-fulldeps tests and is distributed by default for all target standard library packages. Currenly this includes a number of unstable crates which are rarely used such as `graphviz` and `rbml`> This commit trims down the set of `TARGET_CRATES`, moves a number of tests to `*-fulldeps` as a result, and trims down the dependencies of libtest so we can distribute fewer crates in the `rust-std` packages.
2016-03-02 00:00:18 -06:00
TARGET_CRATES := libc std term \
getopts collections test rand \
crate-ify compiler-rt into compiler-builtins libcompiler-rt.a is dead, long live libcompiler-builtins.rlib This commit moves the logic that used to build libcompiler-rt.a into a compiler-builtins crate on top of the core crate and below the std crate. This new crate still compiles the compiler-rt instrinsics using gcc-rs but produces an .rlib instead of a static library. Also, with this commit rustc no longer passes -lcompiler-rt to the linker. This effectively makes the "no-compiler-rt" field of target specifications a no-op. Users of `no_std` will have to explicitly add the compiler-builtins crate to their crate dependency graph *if* they need the compiler-rt intrinsics. Users of the `std` have to do nothing extra as the std crate depends on compiler-builtins. Finally, this a step towards lazy compilation of std with Cargo as the compiler-rt intrinsics can now be built by Cargo instead of having to be supplied by the user by some other method. closes #34400
2016-07-24 21:42:11 -05:00
compiler_builtins core alloc \
rustc: Allow changing the default allocator This commit is an implementation of [RFC 1183][rfc] which allows swapping out the default allocator on nightly Rust. No new stable surface area should be added as a part of this commit. [rfc]: https://github.com/rust-lang/rfcs/pull/1183 Two new attributes have been added to the compiler: * `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to indicate that it requires an allocator crate to be in scope. * `#![allocator]` - this is a indicator that the crate is an allocator which can satisfy the `needs_allocator` attribute above. The ABI of the allocator crate is defined to be a set of symbols that implement the standard Rust allocation/deallocation functions. The symbols are not currently checked for exhaustiveness or typechecked. There are also a number of restrictions on these crates: * An allocator crate cannot transitively depend on a crate that is flagged as needing an allocator (e.g. allocator crates can't depend on liballoc). * There can only be one explicitly linked allocator in a final image. * If no allocator is explicitly requested one will be injected on behalf of the compiler. Binaries and Rust dylibs will use jemalloc by default where available and staticlibs/other dylibs will use the system allocator by default. Two allocators are provided by the distribution by default, `alloc_system` and `alloc_jemalloc` which operate as advertised. Closes #27389
2015-06-25 12:07:01 -05:00
rustc_unicode rustc_bitflags \
rustc: Implement custom panic runtimes This commit is an implementation of [RFC 1513] which allows applications to alter the behavior of panics at compile time. A new compiler flag, `-C panic`, is added and accepts the values `unwind` or `panic`, with the default being `unwind`. This model affects how code is generated for the local crate, skipping generation of landing pads with `-C panic=abort`. [RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md Panic implementations are then provided by crates tagged with `#![panic_runtime]` and lazily required by crates with `#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic runtime must match the final product, and if the panic strategy is not `abort` then the entire DAG must have the same panic strategy. With the `-C panic=abort` strategy, users can expect a stable method to disable generation of landing pads, improving optimization in niche scenarios, decreasing compile time, and decreasing output binary size. With the `-C panic=unwind` strategy users can expect the existing ability to isolate failure in Rust code from the outside world. Organizationally, this commit dismantles the `sys_common::unwind` module in favor of some bits moving part of it to `libpanic_unwind` and the rest into the `panicking` module in libstd. The custom panic runtime support is pretty similar to the custom allocator support with the only major difference being how the panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 18:18:40 -05:00
alloc_system alloc_jemalloc \
panic_abort panic_unwind unwind
add MIR crate and link it into the driver
2015-08-18 17:01:44 -05:00
RUSTC_CRATES := rustc rustc_typeck rustc_mir rustc_borrowck rustc_resolve rustc_driver \
Add librustc_data_structures crate
2015-04-07 05:10:53 -05:00
rustc_trans rustc_back rustc_llvm rustc_privacy rustc_lint \
Move errors from libsyntax to its own crate
2016-06-21 17:08:13 -05:00
rustc_data_structures rustc_platform_intrinsics rustc_errors \
mk: move rustc_const_eval to RUSTC_CRATES where it belongs.
2016-03-29 05:51:46 -05:00
rustc_plugin rustc_metadata rustc_passes rustc_save_analysis \
rustc: Rename rustc_macro to proc_macro This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`, which reflects the general consensus of #35900. A follow up PR to Cargo will be required to purge the `rustc-macro` name as well.
2016-10-03 11:49:39 -05:00
rustc_const_eval rustc_const_math rustc_incremental proc_macro
Split up libproc_macro_plugin Separate the plugin code from non-plugin code to break a potential cycle in crates. This will allow us to merge the new libproc_macro_tokens into libproc_macro.
2016-10-21 02:55:39 -05:00
HOST_CRATES := syntax syntax_ext proc_macro_tokens proc_macro_plugin syntax_pos $(RUSTC_CRATES) \
rustdoc fmt_macros flate arena graphviz log serialize
Rename `error-index-generator` to `error_index_generator` This is because the tool compiler passes the name of the tool as a command line `--cfg`. The improved session config parser is stricter and no longer permits invalid meta items (such as "error-index-generator").
2016-02-15 00:26:37 -06:00
TOOLS := compiletest rustdoc rustc rustbook error_index_generator
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
mk: Add libcore
2014-04-30 22:05:14 -05:00
DEPS_core :=
crate-ify compiler-rt into compiler-builtins libcompiler-rt.a is dead, long live libcompiler-builtins.rlib This commit moves the logic that used to build libcompiler-rt.a into a compiler-builtins crate on top of the core crate and below the std crate. This new crate still compiles the compiler-rt instrinsics using gcc-rs but produces an .rlib instead of a static library. Also, with this commit rustc no longer passes -lcompiler-rt to the linker. This effectively makes the "no-compiler-rt" field of target specifications a no-op. Users of `no_std` will have to explicitly add the compiler-builtins crate to their crate dependency graph *if* they need the compiler-rt intrinsics. Users of the `std` have to do nothing extra as the std crate depends on compiler-builtins. Finally, this a step towards lazy compilation of std with Cargo as the compiler-rt intrinsics can now be built by Cargo instead of having to be supplied by the user by some other method. closes #34400
2016-07-24 21:42:11 -05:00
DEPS_compiler_builtins := core
review comments
2015-10-06 14:26:22 -05:00
DEPS_alloc := core libc alloc_system
DEPS_alloc_system := core libc
mk: Move disable-jemalloc logic into makefiles The `--disable-jemalloc` configure option has a failure mode where it will create a distribution that is not compatible with other compilers. For example the nightly for Linux will assume that it will link to jemalloc by default as an allocator for executable crates. If, however, a standard library is used which was built via `./configure --disable-jemalloc` then this will fail because the jemalloc crate wasn't built. While this seems somewhat reasonable as a niche situation, the same mechanism is used for disabling jemalloc for platforms that just don't support it. For example if the rumprun target is compiled then the sibiling Linux target *also* doesn't have jemalloc. This is currently a problem for our cross-build nightlies which build many targets. If rumprun is also built, it will disable jemalloc for all targets, which isn't desired. This commit moves the platform-specific disabling of jemalloc as hardcoded logic into the makefiles that is scoped per-platform. This way when configuring multiple targets **without the `--disable-jemalloc` option specified** all targets will get jemalloc as they should.
2016-02-08 12:57:41 -06:00
DEPS_alloc_jemalloc := core libc native:jemalloc
review comments
2015-10-06 14:26:22 -05:00
DEPS_collections := core alloc rustc_unicode
Move checking of whether fields are Sized or not into wf / trait code.
2014-09-22 19:12:15 -05:00
DEPS_libc := core
review comments
2015-10-06 14:26:22 -05:00
DEPS_rand := core
DEPS_rustc_bitflags := core
deprecate Unicode functions that will be moved to crates.io This patch 1. renames libunicode to librustc_unicode, 2. deprecates several pieces of libunicode (see below), and 3. removes references to deprecated functions from librustc_driver and libsyntax. This may change pretty-printed output from these modules in cases involving wide or combining characters used in filenames, identifiers, etc. The following functions are marked deprecated: 1. char.width() and str.width(): --> use unicode-width crate 2. str.graphemes() and str.grapheme_indices(): --> use unicode-segmentation crate 3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(), char.compose(), char.decompose_canonical(), char.decompose_compatible(), char.canonical_combining_class(): --> use unicode-normalization crate
2015-04-14 14:52:37 -05:00
DEPS_rustc_unicode := core
rustc: Implement custom panic runtimes This commit is an implementation of [RFC 1513] which allows applications to alter the behavior of panics at compile time. A new compiler flag, `-C panic`, is added and accepts the values `unwind` or `panic`, with the default being `unwind`. This model affects how code is generated for the local crate, skipping generation of landing pads with `-C panic=abort`. [RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md Panic implementations are then provided by crates tagged with `#![panic_runtime]` and lazily required by crates with `#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic runtime must match the final product, and if the panic strategy is not `abort` then the entire DAG must have the same panic strategy. With the `-C panic=abort` strategy, users can expect a stable method to disable generation of landing pads, improving optimization in niche scenarios, decreasing compile time, and decreasing output binary size. With the `-C panic=unwind` strategy users can expect the existing ability to isolate failure in Rust code from the outside world. Organizationally, this commit dismantles the `sys_common::unwind` module in favor of some bits moving part of it to `libpanic_unwind` and the rest into the `panicking` module in libstd. The custom panic runtime support is pretty similar to the custom allocator support with the only major difference being how the panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 18:18:40 -05:00
DEPS_panic_abort := libc alloc
DEPS_panic_unwind := libc alloc unwind
DEPS_unwind := libc
crate-ify compiler-rt into compiler-builtins libcompiler-rt.a is dead, long live libcompiler-builtins.rlib This commit moves the logic that used to build libcompiler-rt.a into a compiler-builtins crate on top of the core crate and below the std crate. This new crate still compiles the compiler-rt instrinsics using gcc-rs but produces an .rlib instead of a static library. Also, with this commit rustc no longer passes -lcompiler-rt to the linker. This effectively makes the "no-compiler-rt" field of target specifications a no-op. Users of `no_std` will have to explicitly add the compiler-builtins crate to their crate dependency graph *if* they need the compiler-rt intrinsics. Users of the `std` have to do nothing extra as the std crate depends on compiler-builtins. Finally, this a step towards lazy compilation of std with Cargo as the compiler-rt intrinsics can now be built by Cargo instead of having to be supplied by the user by some other method. closes #34400
2016-07-24 21:42:11 -05:00
RUSTFLAGS_compiler_builtins := -lstatic=compiler-rt
rustc: Implement custom panic runtimes This commit is an implementation of [RFC 1513] which allows applications to alter the behavior of panics at compile time. A new compiler flag, `-C panic`, is added and accepts the values `unwind` or `panic`, with the default being `unwind`. This model affects how code is generated for the local crate, skipping generation of landing pads with `-C panic=abort`. [RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md Panic implementations are then provided by crates tagged with `#![panic_runtime]` and lazily required by crates with `#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic runtime must match the final product, and if the panic strategy is not `abort` then the entire DAG must have the same panic strategy. With the `-C panic=abort` strategy, users can expect a stable method to disable generation of landing pads, improving optimization in niche scenarios, decreasing compile time, and decreasing output binary size. With the `-C panic=unwind` strategy users can expect the existing ability to isolate failure in Rust code from the outside world. Organizationally, this commit dismantles the `sys_common::unwind` module in favor of some bits moving part of it to `libpanic_unwind` and the rest into the `panicking` module in libstd. The custom panic runtime support is pretty similar to the custom allocator support with the only major difference being how the panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 18:18:40 -05:00
# FIXME(stage0): change this to just `RUSTFLAGS_panic_abort := ...`
RUSTFLAGS1_panic_abort := -C panic=abort
RUSTFLAGS2_panic_abort := -C panic=abort
RUSTFLAGS3_panic_abort := -C panic=abort
review comments
2015-10-06 14:26:22 -05:00
crate-ify compiler-rt into compiler-builtins libcompiler-rt.a is dead, long live libcompiler-builtins.rlib This commit moves the logic that used to build libcompiler-rt.a into a compiler-builtins crate on top of the core crate and below the std crate. This new crate still compiles the compiler-rt instrinsics using gcc-rs but produces an .rlib instead of a static library. Also, with this commit rustc no longer passes -lcompiler-rt to the linker. This effectively makes the "no-compiler-rt" field of target specifications a no-op. Users of `no_std` will have to explicitly add the compiler-builtins crate to their crate dependency graph *if* they need the compiler-rt intrinsics. Users of the `std` have to do nothing extra as the std crate depends on compiler-builtins. Finally, this a step towards lazy compilation of std with Cargo as the compiler-rt intrinsics can now be built by Cargo instead of having to be supplied by the user by some other method. closes #34400
2016-07-24 21:42:11 -05:00
DEPS_std := core libc rand alloc collections compiler_builtins rustc_unicode \
std: Remove rust_builtin C support library All these definitions can now be written in Rust, so do so!
2015-12-02 12:31:29 -06:00
native:backtrace \
rustc: Implement custom panic runtimes This commit is an implementation of [RFC 1513] which allows applications to alter the behavior of panics at compile time. A new compiler flag, `-C panic`, is added and accepts the values `unwind` or `panic`, with the default being `unwind`. This model affects how code is generated for the local crate, skipping generation of landing pads with `-C panic=abort`. [RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md Panic implementations are then provided by crates tagged with `#![panic_runtime]` and lazily required by crates with `#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic runtime must match the final product, and if the panic strategy is not `abort` then the entire DAG must have the same panic strategy. With the `-C panic=abort` strategy, users can expect a stable method to disable generation of landing pads, improving optimization in niche scenarios, decreasing compile time, and decreasing output binary size. With the `-C panic=unwind` strategy users can expect the existing ability to isolate failure in Rust code from the outside world. Organizationally, this commit dismantles the `sys_common::unwind` module in favor of some bits moving part of it to `libpanic_unwind` and the rest into the `panicking` module in libstd. The custom panic runtime support is pretty similar to the custom allocator support with the only major difference being how the panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 18:18:40 -05:00
alloc_system panic_abort panic_unwind unwind
review comments
2015-10-06 14:26:22 -05:00
DEPS_arena := std
DEPS_glob := std
DEPS_flate := std native:miniz
DEPS_fmt_macros = std
DEPS_getopts := std
Graphviz based flow graph pretty-printing. Passing `--pretty flowgraph=<NODEID>` makes rustc print a control flow graph. In pratice, you will also need to pass the additional option: `-o <FILE>` to emit output to a `.dot` file for graphviz. (You can only print the flow-graph for a particular block in the AST.) ---- An interesting implementation detail is the way the code puts both the node index (`cfg::CFGIndex`) and a reference to the payload (`cfg::CFGNode`) into the single `Node` type that is used for labelling and walking the graph. I had once mistakenly thought that I only wanted the `cfg::CFGNode`, but for labelling, you really want the cfg index too, rather than e.g. trying to use the `ast::NodeId` as the label (which breaks down e.g. due to `ast::DUMMY_NODE_ID`). ---- As a drive-by fix, I had to fix `rustc::middle::cfg::construct` interface to reflect changes that have happened on the master branch while I was getting this integrated into the compiler. (The next commit actually adds tests of the `--pretty flowgraph` functionality, so that should ensure that the `rustc::middle::cfg` code does not go stale again.)
2014-04-17 14:00:08 -05:00
DEPS_graphviz := std
review comments
2015-10-06 14:26:22 -05:00
DEPS_log := std
DEPS_num := std
DEPS_serialize := std log
mk: Distribute fewer TARGET_CRATES Right now everything in TARGET_CRATES is built by default for all non-fulldeps tests and is distributed by default for all target standard library packages. Currenly this includes a number of unstable crates which are rarely used such as `graphviz` and `rbml`> This commit trims down the set of `TARGET_CRATES`, moves a number of tests to `*-fulldeps` as a result, and trims down the dependencies of libtest so we can distribute fewer crates in the `rust-std` packages.
2016-03-02 00:00:18 -06:00
DEPS_term := std
DEPS_test := std getopts term native:rust_test_helpers
review comments
2015-10-06 14:26:22 -05:00
Move errors from libsyntax to its own crate
2016-06-21 17:08:13 -05:00
DEPS_syntax := std term serialize log arena libc rustc_bitflags rustc_unicode rustc_errors syntax_pos
rustc: Rename rustc_macro to proc_macro This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`, which reflects the general consensus of #35900. A follow up PR to Cargo will be required to purge the `rustc-macro` name as well.
2016-10-03 11:49:39 -05:00
DEPS_syntax_ext := syntax syntax_pos rustc_errors fmt_macros proc_macro
Move errors from libsyntax to its own crate
2016-06-21 17:08:13 -05:00
DEPS_syntax_pos := serialize
Split up libproc_macro_plugin Separate the plugin code from non-plugin code to break a potential cycle in crates. This will allow us to merge the new libproc_macro_tokens into libproc_macro.
2016-10-21 02:55:39 -05:00
DEPS_proc_macro_tokens := syntax syntax_pos log
DEPS_proc_macro_plugin := syntax syntax_pos rustc_plugin log proc_macro_tokens
review comments
2015-10-06 14:26:22 -05:00
rename `rustc_const_eval` to `rustc_const_math`
2016-03-15 06:33:13 -05:00
DEPS_rustc_const_math := std syntax log serialize
rustc: move rustc_front to rustc::hir.
2016-03-29 00:50:44 -05:00
DEPS_rustc_const_eval := rustc_const_math rustc syntax log serialize \
Move errors from libsyntax to its own crate
2016-06-21 17:08:13 -05:00
rustc_back graphviz syntax_pos
typestrong constant integers
2015-12-16 11:44:15 -06:00
Remove librbml and the RBML-tagged auto-encoder/decoder.
2016-09-01 08:55:33 -05:00
DEPS_rustc := syntax fmt_macros flate arena serialize getopts \
Reintroduce rustc_llvm dependency in rustc The dependency was removed in 352b44d1fa9ec2c969d7c8360106e6838233bcba, but it is needed in order to compute the target features.
2016-03-30 05:11:58 -05:00
log graphviz rustc_llvm rustc_back rustc_data_structures\
Move errors from libsyntax to its own crate
2016-06-21 17:08:13 -05:00
rustc_const_math syntax_pos rustc_errors
rustc: move rustc_front to rustc::hir.
2016-03-29 00:50:44 -05:00
DEPS_rustc_back := std syntax flate log libc
Move errors from libsyntax to its own crate
2016-06-21 17:08:13 -05:00
DEPS_rustc_borrowck := rustc log graphviz syntax syntax_pos rustc_errors rustc_mir
Move `flock.rs` from librustdoc to librustc_data_structures.
2016-08-12 17:22:02 -05:00
DEPS_rustc_data_structures := std log serialize libc
Separate borrowck into its own crate and remove dead code as well.
2014-12-05 13:17:35 -06:00
DEPS_rustc_driver := arena flate getopts graphviz libc rustc rustc_back rustc_borrowck \
add MIR crate and link it into the driver
2015-08-18 17:01:44 -05:00
rustc_typeck rustc_mir rustc_resolve log syntax serialize rustc_llvm \
Proc_macro is alive
2016-08-04 14:20:01 -05:00
rustc_trans rustc_privacy rustc_lint rustc_plugin \
rustc: Rename rustc_macro to proc_macro This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`, which reflects the general consensus of #35900. A follow up PR to Cargo will be required to purge the `rustc-macro` name as well.
2016-10-03 11:49:39 -05:00
rustc_metadata syntax_ext proc_macro_plugin \
Proc_macro is alive
2016-08-04 14:20:01 -05:00
rustc_passes rustc_save_analysis rustc_const_eval \
Add rustc_data_structures to rustc_driver dependencies.
2016-10-28 20:26:01 -05:00
rustc_incremental syntax_pos rustc_errors proc_macro rustc_data_structures
Move errors from libsyntax to its own crate
2016-06-21 17:08:13 -05:00
DEPS_rustc_errors := log libc serialize syntax_pos
DEPS_rustc_lint := rustc log syntax syntax_pos rustc_const_eval
rustc: Allow changing the default allocator This commit is an implementation of [RFC 1183][rfc] which allows swapping out the default allocator on nightly Rust. No new stable surface area should be added as a part of this commit. [rfc]: https://github.com/rust-lang/rfcs/pull/1183 Two new attributes have been added to the compiler: * `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to indicate that it requires an allocator crate to be in scope. * `#![allocator]` - this is a indicator that the crate is an allocator which can satisfy the `needs_allocator` attribute above. The ABI of the allocator crate is defined to be a set of symbols that implement the standard Rust allocation/deallocation functions. The symbols are not currently checked for exhaustiveness or typechecked. There are also a number of restrictions on these crates: * An allocator crate cannot transitively depend on a crate that is flagged as needing an allocator (e.g. allocator crates can't depend on liballoc). * There can only be one explicitly linked allocator in a final image. * If no allocator is explicitly requested one will be injected on behalf of the compiler. Binaries and Rust dylibs will use jemalloc by default where available and staticlibs/other dylibs will use the system allocator by default. Two allocators are provided by the distribution by default, `alloc_system` and `alloc_jemalloc` which operate as advertised. Closes #27389
2015-06-25 12:07:01 -05:00
DEPS_rustc_llvm := native:rustllvm libc std rustc_bitflags
rustc: Rename rustc_macro to proc_macro This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`, which reflects the general consensus of #35900. A follow up PR to Cargo will be required to purge the `rustc-macro` name as well.
2016-10-03 11:49:39 -05:00
DEPS_proc_macro := std syntax
Remove librbml and the RBML-tagged auto-encoder/decoder.
2016-09-01 08:55:33 -05:00
DEPS_rustc_metadata := rustc syntax syntax_pos rustc_errors rustc_const_math \
rustc: Rename rustc_macro to proc_macro This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`, which reflects the general consensus of #35900. A follow up PR to Cargo will be required to purge the `rustc-macro` name as well.
2016-10-03 11:49:39 -05:00
proc_macro syntax_ext
Move errors from libsyntax to its own crate
2016-06-21 17:08:13 -05:00
DEPS_rustc_passes := syntax syntax_pos rustc core rustc_const_eval rustc_errors
DEPS_rustc_mir := rustc syntax syntax_pos rustc_const_math rustc_const_eval rustc_bitflags
DEPS_rustc_resolve := arena rustc log syntax syntax_pos rustc_errors
rustc_platform_intrinsics: remove unused rustc dependency.
2016-03-29 05:50:58 -05:00
DEPS_rustc_platform_intrinsics := std
Move errors from libsyntax to its own crate
2016-06-21 17:08:13 -05:00
DEPS_rustc_plugin := rustc rustc_metadata syntax syntax_pos rustc_errors
DEPS_rustc_privacy := rustc log syntax syntax_pos
remove the librustc_trans -> librustc_mir dependency
2016-06-05 11:38:22 -05:00
DEPS_rustc_trans := arena flate getopts graphviz libc rustc rustc_back \
rustc: move rustc_front to rustc::hir.
2016-03-29 00:50:44 -05:00
log syntax serialize rustc_llvm rustc_platform_intrinsics \
Move errors from libsyntax to its own crate
2016-06-21 17:08:13 -05:00
rustc_const_math rustc_const_eval rustc_incremental rustc_errors syntax_pos
Remove librbml and the RBML-tagged auto-encoder/decoder.
2016-09-01 08:55:33 -05:00
DEPS_rustc_incremental := rustc syntax_pos serialize rustc_data_structures
Move errors from libsyntax to its own crate
2016-06-21 17:08:13 -05:00
DEPS_rustc_save_analysis := rustc log syntax syntax_pos serialize
DEPS_rustc_typeck := rustc syntax syntax_pos rustc_platform_intrinsics rustc_const_math \
rustc_const_eval rustc_errors
review comments
2015-10-06 14:26:22 -05:00
Move `flock.rs` from librustdoc to librustc_data_structures.
2016-08-12 17:22:02 -05:00
DEPS_rustdoc := rustc rustc_driver native:hoedown serialize getopts test \
rustc_lint rustc_const_eval syntax_pos rustc_data_structures
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
port compiletest to use JSON output This uncovered a lot of bugs in compiletest and also some shortcomings of our existing JSON output. We had to add information to the JSON output, such as suggested text and macro backtraces. We also had to fix various bugs in the existing tests. Joint work with jntrnr.
2016-04-15 20:23:50 -05:00
TOOL_DEPS_compiletest := test getopts log serialize
Remove libnative With runtime removal complete, there's nothing left of libnative. This commit removes it. Fixes #18687 [breaking-change]
2014-11-14 15:55:57 -06:00
TOOL_DEPS_rustdoc := rustdoc
Separate the driver into its own crate that uses trans, typeck.
2014-11-27 08:57:47 -06:00
TOOL_DEPS_rustc := rustc_driver
regex: Remove in-tree version The regex library was largely used for non-critical aspects of the compiler and various external tooling. The library at this point is duplicated with its out-of-tree counterpart and as such imposes a bit of a maintenance overhead as well as compile time hit for the compiler itself. The last major user of the regex library is the libtest library, using regexes for filters when running tests. This removal means that the filtering has gone back to substring matching rather than using regexes.
2015-01-20 12:45:29 -06:00
TOOL_DEPS_rustbook := std rustdoc
Rename `error-index-generator` to `error_index_generator` This is because the tool compiler passes the name of the tool as a command line `--cfg`. The improved session config parser is stricter and no longer permits invalid meta items (such as "error-index-generator").
2016-02-15 00:26:37 -06:00
TOOL_DEPS_error_index_generator := rustdoc syntax serialize
rustbuild: Add support for compiletest test suites This commit adds support in rustbuild for running all of the compiletest test suites as part of `make check`. The `compiletest` program was moved to `src/tools` (like `rustbook` and others) and is now just compiled like any other old tool. Each test suite has a pretty standard set of dependencies and just tweaks various parameters to the final compiletest executable. Note that full support is lacking in terms of: * Once a test suite has passed, that's not remembered. When a test suite is requested to be run, it's always run. * The arguments to compiletest probably don't work for every possible combination of platforms and testing environments just yet. There will likely need to be future updates to tweak various pieces here and there. * Cross compiled test suites probably don't work just yet, support for that will come in a follow-up patch.
2016-04-05 13:34:23 -05:00
TOOL_SOURCE_compiletest := $(S)src/tools/compiletest/src/main.rs
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
TOOL_SOURCE_rustdoc := $(S)src/driver/driver.rs
TOOL_SOURCE_rustc := $(S)src/driver/driver.rs
rustbuild: Move rustbook to a `src/tools` directory We've actually got quite a few tools that are compiled as part of our build, let's start housing them all in a `tools` directory.
2016-03-08 00:32:37 -06:00
TOOL_SOURCE_rustbook := $(S)src/tools/rustbook/main.rs
rustbuild: Add the error-index-generator This adds a step and a rule for building the error index as part of rustbuild.
2016-03-08 15:42:32 -06:00
TOOL_SOURCE_error_index_generator := $(S)src/tools/error_index_generator/main.rs
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
crate-ify compiler-rt into compiler-builtins libcompiler-rt.a is dead, long live libcompiler-builtins.rlib This commit moves the logic that used to build libcompiler-rt.a into a compiler-builtins crate on top of the core crate and below the std crate. This new crate still compiles the compiler-rt instrinsics using gcc-rs but produces an .rlib instead of a static library. Also, with this commit rustc no longer passes -lcompiler-rt to the linker. This effectively makes the "no-compiler-rt" field of target specifications a no-op. Users of `no_std` will have to explicitly add the compiler-builtins crate to their crate dependency graph *if* they need the compiler-rt intrinsics. Users of the `std` have to do nothing extra as the std crate depends on compiler-builtins. Finally, this a step towards lazy compilation of std with Cargo as the compiler-rt intrinsics can now be built by Cargo instead of having to be supplied by the user by some other method. closes #34400
2016-07-24 21:42:11 -05:00
ONLY_RLIB_compiler_builtins := 1
mk: Add libcore
2014-04-30 22:05:14 -05:00
ONLY_RLIB_core := 1
libc: only provide an rlib. There's absolutely no reason for `libc` to be offered as a dynamic library.
2014-06-03 18:12:11 -05:00
ONLY_RLIB_libc := 1
std: Refactor liballoc out of lib{std,sync} This commit is part of the libstd facade RFC, issue #13851. This creates a new library, liballoc, which is intended to be the core allocation library for all of Rust. It is pinned on the basic assumption that an allocation failure is an abort or failure. This module has inherited the heap/libc_heap modules from std::rt, the owned/rc modules from std, and the arc module from libsync. These three pointers are currently the three most core pointer implementations in Rust. The UnsafeArc type in std::sync should be considered deprecated and replaced by Arc<Unsafe<T>>. This commit does not currently migrate to this type, but future commits will continue this refactoring.
2014-05-13 18:10:05 -05:00
ONLY_RLIB_alloc := 1
std: Recreate a `rand` module This commit shuffles around some of the `rand` code, along with some reorganization. The new state of the world is as follows: * The librand crate now only depends on libcore. This interface is experimental. * The standard library has a new module, `std::rand`. This interface will eventually become stable. Unfortunately, this entailed more of a breaking change than just shuffling some names around. The following breaking changes were made to the rand library: * Rng::gen_vec() was removed. This has been replaced with Rng::gen_iter() which will return an infinite stream of random values. Previous behavior can be regained with `rng.gen_iter().take(n).collect()` * Rng::gen_ascii_str() was removed. This has been replaced with Rng::gen_ascii_chars() which will return an infinite stream of random ascii characters. Similarly to gen_iter(), previous behavior can be emulated with `rng.gen_ascii_chars().take(n).collect()` * {IsaacRng, Isaac64Rng, XorShiftRng}::new() have all been removed. These all relied on being able to use an OSRng for seeding, but this is no longer available in librand (where these types are defined). To retain the same functionality, these types now implement the `Rand` trait so they can be generated with a random seed from another random number generator. This allows the stdlib to use an OSRng to create seeded instances of these RNGs. * Rand implementations for `Box<T>` and `@T` were removed. These seemed to be pretty rare in the codebase, and it allows for librand to not depend on liballoc. Additionally, other pointer types like Rc<T> and Arc<T> were not supported. If this is undesirable, librand can depend on liballoc and regain these implementations. * The WeightedChoice structure is no longer built with a `Vec<Weighted<T>>`, but rather a `&mut [Weighted<T>]`. This means that the WeightedChoice structure now has a lifetime associated with it. * The `sample` method on `Rng` has been moved to a top-level function in the `rand` module due to its dependence on `Vec`. cc #13851 [breaking-change]
2014-05-25 03:39:37 -05:00
ONLY_RLIB_rand := 1
std: Recreate a `collections` module As with the previous commit with `librand`, this commit shuffles around some `collections` code. The new state of the world is similar to that of librand: * The libcollections crate now only depends on libcore and liballoc. * The standard library has a new module, `std::collections`. All functionality of libcollections is reexported through this module. I would like to stress that this change is purely cosmetic. There are very few alterations to these primitives. There are a number of notable points about the new organization: * std::{str, slice, string, vec} all moved to libcollections. There is no reason that these primitives shouldn't be necessarily usable in a freestanding context that has allocation. These are all reexported in their usual places in the standard library. * The `hashmap`, and transitively the `lru_cache`, modules no longer reside in `libcollections`, but rather in libstd. The reason for this is because the `HashMap::new` contructor requires access to the OSRng for initially seeding the hash map. Beyond this requirement, there is no reason that the hashmap could not move to libcollections. I do, however, have a plan to move the hash map to the collections module. The `HashMap::new` function could be altered to require that the `H` hasher parameter ascribe to the `Default` trait, allowing the entire `hashmap` module to live in libcollections. The key idea would be that the default hasher would be different in libstd. Something along the lines of: // src/libstd/collections/mod.rs pub type HashMap<K, V, H = RandomizedSipHasher> = core_collections::HashMap<K, V, H>; This is not possible today because you cannot invoke static methods through type aliases. If we modified the compiler, however, to allow invocation of static methods through type aliases, then this type definition would essentially be switching the default hasher from `SipHasher` in libcollections to a libstd-defined `RandomizedSipHasher` type. This type's `Default` implementation would randomly seed the `SipHasher` instance, and otherwise perform the same as `SipHasher`. This future state doesn't seem incredibly far off, but until that time comes, the hashmap module will live in libstd to not compromise on functionality. * In preparation for the hashmap moving to libcollections, the `hash` module has moved from libstd to libcollections. A previously snapshotted commit enables a distinct `Writer` trait to live in the `hash` module which `Hash` implementations are now parameterized over. Due to using a custom trait, the `SipHasher` implementation has lost its specialized methods for writing integers. These can be re-added backwards-compatibly in the future via default methods if necessary, but the FNV hashing should satisfy much of the need for speedier hashing. A list of breaking changes: * HashMap::{get, get_mut} no longer fails with the key formatted into the error message with `{:?}`, instead, a generic message is printed. With backtraces, it should still be not-too-hard to track down errors. * The HashMap, HashSet, and LruCache types are now available through std::collections instead of the collections crate. * Manual implementations of hash should be parameterized over `hash::Writer` instead of just `Writer`. [breaking-change]
2014-05-29 20:50:12 -05:00
ONLY_RLIB_collections := 1
deprecate Unicode functions that will be moved to crates.io This patch 1. renames libunicode to librustc_unicode, 2. deprecates several pieces of libunicode (see below), and 3. removes references to deprecated functions from librustc_driver and libsyntax. This may change pretty-printed output from these modules in cases involving wide or combining characters used in filenames, identifiers, etc. The following functions are marked deprecated: 1. char.width() and str.width(): --> use unicode-width crate 2. str.graphemes() and str.grapheme_indices(): --> use unicode-segmentation crate 3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(), char.compose(), char.decompose_canonical(), char.decompose_compatible(), char.canonical_combining_class(): --> use unicode-normalization crate
2015-04-14 14:52:37 -05:00
ONLY_RLIB_rustc_unicode := 1
std: Move the bitflags! macro to a gated crate In accordance with [collections reform part 2][rfc] this macro has been moved to an external [bitflags crate][crate] which is [available though crates.io][cratesio]. Inside the standard distribution the macro has been moved to a crate called `rustc_bitflags` for current users to continue using. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0509-collections-reform-part-2.md [crate]: https://github.com/rust-lang/bitflags [cratesio]: http://crates.io/crates/bitflags The major user of `bitflags!` in terms of a public-facing possibly-stable API today is the `FilePermissions` structure inside of `std::io`. This user, however, will likely no longer use `bitflags!` after I/O reform has landed. To prevent breaking APIs today, this structure remains as-is. Current users of the `bitflags!` macro should add this to their `Cargo.toml`: bitflags = "0.1" and this to their crate root: #[macro_use] extern crate bitflags; Due to the removal of a public macro, this is a: [breaking-change]
2015-01-16 14:20:03 -06:00
ONLY_RLIB_rustc_bitflags := 1
rustc: Allow changing the default allocator This commit is an implementation of [RFC 1183][rfc] which allows swapping out the default allocator on nightly Rust. No new stable surface area should be added as a part of this commit. [rfc]: https://github.com/rust-lang/rfcs/pull/1183 Two new attributes have been added to the compiler: * `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to indicate that it requires an allocator crate to be in scope. * `#![allocator]` - this is a indicator that the crate is an allocator which can satisfy the `needs_allocator` attribute above. The ABI of the allocator crate is defined to be a set of symbols that implement the standard Rust allocation/deallocation functions. The symbols are not currently checked for exhaustiveness or typechecked. There are also a number of restrictions on these crates: * An allocator crate cannot transitively depend on a crate that is flagged as needing an allocator (e.g. allocator crates can't depend on liballoc). * There can only be one explicitly linked allocator in a final image. * If no allocator is explicitly requested one will be injected on behalf of the compiler. Binaries and Rust dylibs will use jemalloc by default where available and staticlibs/other dylibs will use the system allocator by default. Two allocators are provided by the distribution by default, `alloc_system` and `alloc_jemalloc` which operate as advertised. Closes #27389
2015-06-25 12:07:01 -05:00
ONLY_RLIB_alloc_system := 1
mk: Move disable-jemalloc logic into makefiles The `--disable-jemalloc` configure option has a failure mode where it will create a distribution that is not compatible with other compilers. For example the nightly for Linux will assume that it will link to jemalloc by default as an allocator for executable crates. If, however, a standard library is used which was built via `./configure --disable-jemalloc` then this will fail because the jemalloc crate wasn't built. While this seems somewhat reasonable as a niche situation, the same mechanism is used for disabling jemalloc for platforms that just don't support it. For example if the rumprun target is compiled then the sibiling Linux target *also* doesn't have jemalloc. This is currently a problem for our cross-build nightlies which build many targets. If rumprun is also built, it will disable jemalloc for all targets, which isn't desired. This commit moves the platform-specific disabling of jemalloc as hardcoded logic into the makefiles that is scoped per-platform. This way when configuring multiple targets **without the `--disable-jemalloc` option specified** all targets will get jemalloc as they should.
2016-02-08 12:57:41 -06:00
ONLY_RLIB_alloc_jemalloc := 1
rustc: Implement custom panic runtimes This commit is an implementation of [RFC 1513] which allows applications to alter the behavior of panics at compile time. A new compiler flag, `-C panic`, is added and accepts the values `unwind` or `panic`, with the default being `unwind`. This model affects how code is generated for the local crate, skipping generation of landing pads with `-C panic=abort`. [RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md Panic implementations are then provided by crates tagged with `#![panic_runtime]` and lazily required by crates with `#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic runtime must match the final product, and if the panic strategy is not `abort` then the entire DAG must have the same panic strategy. With the `-C panic=abort` strategy, users can expect a stable method to disable generation of landing pads, improving optimization in niche scenarios, decreasing compile time, and decreasing output binary size. With the `-C panic=unwind` strategy users can expect the existing ability to isolate failure in Rust code from the outside world. Organizationally, this commit dismantles the `sys_common::unwind` module in favor of some bits moving part of it to `libpanic_unwind` and the rest into the `panicking` module in libstd. The custom panic runtime support is pretty similar to the custom allocator support with the only major difference being how the panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 18:18:40 -05:00
ONLY_RLIB_panic_unwind := 1
ONLY_RLIB_panic_abort := 1
ONLY_RLIB_unwind := 1
mk: Move disable-jemalloc logic into makefiles The `--disable-jemalloc` configure option has a failure mode where it will create a distribution that is not compatible with other compilers. For example the nightly for Linux will assume that it will link to jemalloc by default as an allocator for executable crates. If, however, a standard library is used which was built via `./configure --disable-jemalloc` then this will fail because the jemalloc crate wasn't built. While this seems somewhat reasonable as a niche situation, the same mechanism is used for disabling jemalloc for platforms that just don't support it. For example if the rumprun target is compiled then the sibiling Linux target *also* doesn't have jemalloc. This is currently a problem for our cross-build nightlies which build many targets. If rumprun is also built, it will disable jemalloc for all targets, which isn't desired. This commit moves the platform-specific disabling of jemalloc as hardcoded logic into the makefiles that is scoped per-platform. This way when configuring multiple targets **without the `--disable-jemalloc` option specified** all targets will get jemalloc as they should.
2016-02-08 12:57:41 -06:00
TARGET_SPECIFIC_alloc_jemalloc := 1
mk: Add libcore
2014-04-30 22:05:14 -05:00
mk: Stop documenating non-facade crates This commit ceases documentation-by-default of crates such as `term`, `serialize`, and `alloc`. Crates like `term` and `rand` have duplicates on `crates.io` and the search index entries generated in the local tree end up only leading to confusion. Crates like the entire compiler infrastructure, `flate`, or `rbml` don't need to be documented in such a prominent location. This change also means that doc tests will no longer be run for crates beyond the facade (e.g. `serialize` or `term`), but there were very few doc tests in there to begin with. Closes #22168
2015-04-07 17:11:16 -05:00
# Documented-by-default crates
deprecate Unicode functions that will be moved to crates.io This patch 1. renames libunicode to librustc_unicode, 2. deprecates several pieces of libunicode (see below), and 3. removes references to deprecated functions from librustc_driver and libsyntax. This may change pretty-printed output from these modules in cases involving wide or combining characters used in filenames, identifiers, etc. The following functions are marked deprecated: 1. char.width() and str.width(): --> use unicode-width crate 2. str.graphemes() and str.grapheme_indices(): --> use unicode-segmentation crate 3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(), char.compose(), char.decompose_canonical(), char.decompose_compatible(), char.canonical_combining_class(): --> use unicode-normalization crate
2015-04-14 14:52:37 -05:00
DOC_CRATES := std alloc collections core libc rustc_unicode
mk: Stop documenating non-facade crates This commit ceases documentation-by-default of crates such as `term`, `serialize`, and `alloc`. Crates like `term` and `rand` have duplicates on `crates.io` and the search index entries generated in the local tree end up only leading to confusion. Crates like the entire compiler infrastructure, `flate`, or `rbml` don't need to be documented in such a prominent location. This change also means that doc tests will no longer be run for crates beyond the facade (e.g. `serialize` or `term`), but there were very few doc tests in there to begin with. Closes #22168
2015-04-07 17:11:16 -05:00
Revert "mk: fix some undefined variable warnings" This reverts commit d03712977d7c913044f2b863269c4491d7fa7c36.
2016-02-02 01:27:04 -06:00
ifeq ($(CFG_DISABLE_JEMALLOC),)
rustc_back: Fix disabling jemalloc When building with Cargo we need to detect `feature = "jemalloc"` to enable jemalloc, so propagate this same change to the build system to pass the right `--cfg` argument.
2016-01-21 20:37:46 -06:00
RUSTFLAGS_rustc_back := --cfg 'feature="jemalloc"'
rustc: Allow changing the default allocator This commit is an implementation of [RFC 1183][rfc] which allows swapping out the default allocator on nightly Rust. No new stable surface area should be added as a part of this commit. [rfc]: https://github.com/rust-lang/rfcs/pull/1183 Two new attributes have been added to the compiler: * `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to indicate that it requires an allocator crate to be in scope. * `#![allocator]` - this is a indicator that the crate is an allocator which can satisfy the `needs_allocator` attribute above. The ABI of the allocator crate is defined to be a set of symbols that implement the standard Rust allocation/deallocation functions. The symbols are not currently checked for exhaustiveness or typechecked. There are also a number of restrictions on these crates: * An allocator crate cannot transitively depend on a crate that is flagged as needing an allocator (e.g. allocator crates can't depend on liballoc). * There can only be one explicitly linked allocator in a final image. * If no allocator is explicitly requested one will be injected on behalf of the compiler. Binaries and Rust dylibs will use jemalloc by default where available and staticlibs/other dylibs will use the system allocator by default. Two allocators are provided by the distribution by default, `alloc_system` and `alloc_jemalloc` which operate as advertised. Closes #27389
2015-06-25 12:07:01 -05:00
endif
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
################################################################################
# You should not need to edit below this line
################################################################################
rustc: Allow changing the default allocator This commit is an implementation of [RFC 1183][rfc] which allows swapping out the default allocator on nightly Rust. No new stable surface area should be added as a part of this commit. [rfc]: https://github.com/rust-lang/rfcs/pull/1183 Two new attributes have been added to the compiler: * `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to indicate that it requires an allocator crate to be in scope. * `#![allocator]` - this is a indicator that the crate is an allocator which can satisfy the `needs_allocator` attribute above. The ABI of the allocator crate is defined to be a set of symbols that implement the standard Rust allocation/deallocation functions. The symbols are not currently checked for exhaustiveness or typechecked. There are also a number of restrictions on these crates: * An allocator crate cannot transitively depend on a crate that is flagged as needing an allocator (e.g. allocator crates can't depend on liballoc). * There can only be one explicitly linked allocator in a final image. * If no allocator is explicitly requested one will be injected on behalf of the compiler. Binaries and Rust dylibs will use jemalloc by default where available and staticlibs/other dylibs will use the system allocator by default. Two allocators are provided by the distribution by default, `alloc_system` and `alloc_jemalloc` which operate as advertised. Closes #27389
2015-06-25 12:07:01 -05:00
CRATES := $(TARGET_CRATES) $(HOST_CRATES)
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
# This macro creates some simple definitions for each crate being built, just
# some munging of all of the parameters above.
#
# $(1) is the crate to generate variables for
define RUST_CRATE
mk: Build crates with relative paths to rustc The path we pass to rustc will be visible in panic messages and backtraces: they will be user visible! Avoid junk in these paths by passing relative paths to rustc. For most advanced users, `libcore` or `libstd` in the path will be a clue to the location -- inside our code, not theirs. Store both the relative path to the source as well as the absolute. Use the relative path where it matters, compiling the main crates, instead of changing all of the build process to cope with relative paths. Example output after this patch: ``` $ ./testunwrap thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362 $ RUST_BACKTRACE=1 ./testunwrap thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362 stack backtrace: 1: 0x7ff59c1e9956 - sys::backtrace::write::h67a542fd2b201576des at ../src/libstd/sys/unix/backtrace.rs:158 2: 0x7ff59c1ed5b6 - panicking::on_panic::h3d21c41cdd5c12d41Xw at ../src/libstd/panicking.rs:58 3: 0x7ff59c1e7b6e - rt::unwind::begin_unwind_inner::h9f3a5440cebb8baeLDw at ../src/libstd/rt/unwind/mod.rs:273 4: 0x7ff59c1e7f84 - rt::unwind::begin_unwind_fmt::h4fe8a903e0c296b0RCw at ../src/libstd/rt/unwind/mod.rs:212 5: 0x7ff59c1eced7 - rust_begin_unwind 6: 0x7ff59c22c11a - panicking::panic_fmt::h00b0cd49c98a9220i5B at ../src/libcore/panicking.rs:64 7: 0x7ff59c22b9e0 - panicking::panic::hf549420c0ee03339P3B at ../src/libcore/panicking.rs:45 8: 0x7ff59c1e621d - option::Option<T>::unwrap::h501963526474862829 9: 0x7ff59c1e61b1 - main::hb5c91ce92347d1e6eaa 10: 0x7ff59c1f1c18 - rust_try_inner 11: 0x7ff59c1f1c05 - rust_try 12: 0x7ff59c1ef374 - rt::lang_start::h7e51e19c6677cffe5Sw at ../src/libstd/rt/unwind/mod.rs:147 at ../src/libstd/rt/unwind/mod.rs:130 at ../src/libstd/rt/mod.rs:128 13: 0x7ff59c1e628e - main 14: 0x7ff59b3f6b44 - __libc_start_main 15: 0x7ff59c1e6078 - <unknown> 16: 0x0 - <unknown> ```
2015-06-12 12:40:07 -05:00
CRATEFILE_$(1) := $$(SREL)src/lib$(1)/lib.rs
mk: Use rwildcard to calculate dependent files The previous dependency calculation was based on an arbitrary set of asterisks at an arbitrary depth, but using the recursive version should be much more robust in figuring out what's dependent. Closes #13118
2014-03-25 17:40:52 -05:00
RSINPUTS_$(1) := $$(call rwildcard,$(S)src/lib$(1)/,*.rs)
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
NATIVE_DEPS_$(1) := $$(patsubst native:%,%,$$(filter native:%,$$(DEPS_$(1))))
endef
$(foreach crate,$(CRATES),$(eval $(call RUST_CRATE,$(crate))))
mk: Move disable-jemalloc logic into makefiles The `--disable-jemalloc` configure option has a failure mode where it will create a distribution that is not compatible with other compilers. For example the nightly for Linux will assume that it will link to jemalloc by default as an allocator for executable crates. If, however, a standard library is used which was built via `./configure --disable-jemalloc` then this will fail because the jemalloc crate wasn't built. While this seems somewhat reasonable as a niche situation, the same mechanism is used for disabling jemalloc for platforms that just don't support it. For example if the rumprun target is compiled then the sibiling Linux target *also* doesn't have jemalloc. This is currently a problem for our cross-build nightlies which build many targets. If rumprun is also built, it will disable jemalloc for all targets, which isn't desired. This commit moves the platform-specific disabling of jemalloc as hardcoded logic into the makefiles that is scoped per-platform. This way when configuring multiple targets **without the `--disable-jemalloc` option specified** all targets will get jemalloc as they should.
2016-02-08 12:57:41 -06:00
# $(1) - crate
# $(2) - target
define RUST_CRATE_DEPS
RUST_DEPS_$(1)_T_$(2) := $$(filter-out native:%,$$(DEPS_$(1)))
endef
$(foreach target,$(CFG_TARGET),\
$(foreach crate,$(CRATES),$(eval $(call RUST_CRATE_DEPS,$(crate),$(target)))))
# $(1) - target
# $(2) - crate
define DEFINE_TARGET_CRATES
ifndef TARGET_SPECIFIC_$(2)
TARGET_CRATES_$(1) += $(2)
endif
endef
$(foreach target,$(CFG_TARGET),\
$(foreach crate,$(TARGET_CRATES),\
$(eval $(call DEFINE_TARGET_CRATES,$(target),$(crate)))))
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
# Similar to the macro above for crates, this macro is for tools
#
# $(1) is the crate to generate variables for
define RUST_TOOL
mk: Use rwildcard to calculate dependent files The previous dependency calculation was based on an arbitrary set of asterisks at an arbitrary depth, but using the recursive version should be much more robust in figuring out what's dependent. Closes #13118
2014-03-25 17:40:52 -05:00
TOOL_INPUTS_$(1) := $$(call rwildcard,$$(dir $$(TOOL_SOURCE_$(1))),*.rs)
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
endef
$(foreach crate,$(TOOLS),$(eval $(call RUST_TOOL,$(crate))))
std: Add an option to disable ELF based TLS This commit adds a ./configure option called `--disable-elf-tls` which disables ELF based TLS (that which is communicated to LLVM) on platforms which already support it. OSX 10.6 does not support this form of TLS, and some users of Rust need to target 10.6 and are unable to do so due to the usage of TLS. The standard library will continue to use ELF based TLS on OSX by default (as the officially supported platform is 10.7+), but this adds an option to compile the standard library in a way that is compatible with 10.6.
2015-05-28 01:24:27 -05:00
std: Migrate to the new libc * Delete `sys::unix::{c, sync}` as these are now all folded into libc itself * Update all references to use `libc` as a result. * Update all references to the new flat namespace. * Moves all windows bindings into sys::c
2015-11-02 18:23:22 -06:00
CRATEFILE_libc := $(SREL)src/liblibc/src/lib.rs
RUSTFLAGS_libc := --cfg stdbuild
Reference in New Issue Copy Permalink