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

231 lines
8.2 KiB
Makefile
Raw Normal View History

Reliciense makefiles and testsuite. Yup.
2012-12-10 19:32:48 -06:00
# Copyright 2012 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.
Define rustc's host triple at compile time This way a cross-compiled rustc's answer to host_triple() is correct. The return value of host_triple() reflects the actual host triple that the compiler was build for, not the triple the compiler is being built on
2013-05-25 01:05:31 -05:00
# This is the compile-time target-triple for the compiler. For the compiler at
# runtime, this should be considered the host-triple. More explanation for why
# this exists can be found on issue #2400
mk: Rename CFG_COMPILER to CFG_COMPILER_HOST_TRIPLE Much clearer
2014-03-25 21:23:45 -05:00
export CFG_COMPILER_HOST_TRIPLE
Define rustc's host triple at compile time This way a cross-compiled rustc's answer to host_triple() is correct. The return value of host_triple() reflects the actual host triple that the compiler was build for, not the triple the compiler is being built on
2013-05-25 01:05:31 -05:00
rustc_back: add configure options for default linker and ar Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
2015-08-10 18:09:21 -05:00
# Used as defaults for the runtime ar and cc tools
export CFG_DEFAULT_LINKER
export CFG_DEFAULT_AR
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
# Macro that generates the full list of dependencies for a crate at a particular
# stage/target/host tuple.
#
# $(1) - stage
# $(2) - target
# $(3) - host
# $(4) crate
define RUST_CRATE_FULLDEPS
mk: Remove extra whitespace before line continuation backslashes
2014-07-22 23:37:05 -05:00
CRATE_FULLDEPS_$(1)_T_$(2)_H_$(3)_$(4) := \
$$(CRATEFILE_$(4)) \
$$(RSINPUTS_$(4)) \
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
$$(foreach dep,$$(RUST_DEPS_$(4)_T_$(2)), \
mk: Remove extra whitespace before line continuation backslashes
2014-07-22 23:37:05 -05:00
$$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$$(dep)) \
$$(foreach dep,$$(NATIVE_DEPS_$(4)), \
mk: Add support for musl-based builds This commit adds support to the makefiles, configuration script, and build system to understand MUSL. This is broken up into a few parts: * Any target of the form `*-musl` requires the `--musl-root` option to `./configure` which will indicate the root of the MUSL installation. It is also expected that there is a libunwind build inside of that installation built against that MUSL. * Objects from MUSL are copied into the build tree for Rust to be statically linked into the appropriate Rust library. * Objects for binary startup and shutdown are included in each Rust installation by default for MUSL. This requires MUSL to only be installed on the machine compiling rust. Only a linker will be necessary for compiling against MUSL on a target machine. Eventually a MUSL and/or libunwind build may be integrated by default into the build but for now they are just always assumed to exist externally.
2015-04-21 17:42:05 -05:00
$$(RT_OUTPUT_DIR_$(2))/$$(call CFG_STATIC_LIB_NAME_$(2),$$(dep))) \
$$(foreach dep,$$(NATIVE_DEPS_$(4)_T_$(2)), \
Register new snapshots * Lots of core prelude imports removed * Makefile support for MSVC env vars and Rust crates removed * Makefile support for morestack removed
2015-08-11 16:31:23 -05:00
$$(RT_OUTPUT_DIR_$(2))/$$(dep))
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
mk: Remove extra whitespace before line continuation backslashes
2014-07-22 23:37:05 -05:00
$(foreach host,$(CFG_HOST), \
$(foreach target,$(CFG_TARGET), \
$(foreach stage,$(STAGES), \
$(foreach crate,$(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
$(eval $(call RUST_CRATE_FULLDEPS,$(stage),$(target),$(host),$(crate)))))))
mk: Fix bootstrapping cross-hosts on beta The beta builds are currently failing, unfortunately, due to what is presumably some odd behavior with our makefiles. The wrong bootstrap key is being used to generate the stage1 cross-compiled libraries, which fails the build. Interestingly enough if the targets are directly specified as part of the build then it works just fine! Just a bare `make` fails... Instead of trying to understand what's happening in the makefiles instead just tweak how we configure the bootstrap key in a way that's more likely to work.
2016-05-23 15:45:26 -05:00
# $(1) stage
# $(2) target
# $(3) host
define DEFINE_BOOTSTRAP_KEY
BOOTSTRAP_KEY$(1)_T_$(2)_H_$(3) := $$(CFG_BOOTSTRAP_KEY)
ifeq ($(1),0)
ifeq ($(3),$$(CFG_BUILD))
BOOTSTRAP_KEY$(1)_T_$(2)_H_$(3) := $$(CFG_BOOTSTRAP_KEY_STAGE0)
endif
endif
endef
$(foreach host,$(CFG_TARGET), \
$(foreach target,$(CFG_TARGET), \
$(foreach stage,$(STAGES), \
$(eval $(call DEFINE_BOOTSTRAP_KEY,$(stage),$(target),$(host))))))
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
# RUST_TARGET_STAGE_N template: This defines how target artifacts are built
# for all stage/target architecture combinations. This is one giant rule which
# works as follows:
#
# 1. The immediate dependencies are the rust source files
# 2. Each rust crate dependency is listed (based on their stamp files),
# as well as all native dependencies (listed in RT_OUTPUT_DIR)
Remove morestack support This commit removes all morestack support from the compiler which entails: * Segmented stacks are no longer emitted in codegen. * We no longer build or distribute libmorestack.a * The `stack_exhausted` lang item is no longer required The only current use of the segmented stack support in LLVM is to detect stack overflow. This is no longer really required, however, because we already have guard pages for all threads and registered signal handlers watching for a segfault on those pages (to print out a stack overflow message). Additionally, major platforms (aka Windows) already don't use morestack. This means that Rust is by default less likely to catch stack overflows because if a function takes up more than one page of stack space it won't hit the guard page. This is what the purpose of morestack was (to catch this case), but it's better served with stack probes which have more cross platform support and no runtime support necessary. Until LLVM supports this for all platform it looks like morestack isn't really buying us much. cc #16012 (still need stack probes) Closes #26458 (a drive-by fix to help diagnostics on stack overflow)
2015-07-27 15:41:35 -05:00
# 3. The stage (n-1) compiler is required through the TSREQ dependency
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
# 4. When actually executing the rule, the first thing we do is to clean out
# old libs and rlibs via the REMOVE_ALL_OLD_GLOB_MATCHES macro
# 5. Finally, we get around to building the actual crate. It's just one
# "small" invocation of the previous stage rustc. We use -L to
# RT_OUTPUT_DIR so all the native dependencies are picked up.
# Additionally, we pass in the llvm dir so rustc can link against it.
# 6. Some cleanup is done (listing what was just built) if verbose is turned
# on.
#
basic builds function
2011-11-21 15:11:40 -06:00
# $(1) is the stage
# $(2) is the target triple
# $(3) is the host triple
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
# $(4) is the crate name
define RUST_TARGET_STAGE_N
mk: Rename CFG_COMPILER to CFG_COMPILER_HOST_TRIPLE Much clearer
2014-03-25 21:23:45 -05:00
$$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$(4): CFG_COMPILER_HOST_TRIPLE = $(2)
mk: Fix bootstrapping cross-hosts on beta The beta builds are currently failing, unfortunately, due to what is presumably some odd behavior with our makefiles. The wrong bootstrap key is being used to generate the stage1 cross-compiled libraries, which fails the build. Interestingly enough if the targets are directly specified as part of the build then it works just fine! Just a bare `make` fails... Instead of trying to understand what's happening in the makefiles instead just tweak how we configure the bootstrap key in a way that's more likely to work.
2016-05-23 15:45:26 -05:00
$$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$(4): \
export RUSTC_BOOTSTRAP_KEY := $$(BOOTSTRAP_KEY$(1)_T_$(2)_H_$(3))
mk: Remove extra whitespace before line continuation backslashes
2014-07-22 23:37:05 -05:00
$$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$(4): \
$$(CRATEFILE_$(4)) \
$$(CRATE_FULLDEPS_$(1)_T_$(2)_H_$(3)_$(4)) \
Fix the Linux nightly build by adding a LLVM_CONFIG_<target-triple> dep. The RUST_TARGET_STAGE_N rule uses LLVM_LIBDIR_RUSTFLAGS_<target-triple>, which expands to -L "$(llvm-config --libdir)" when the target-triple is also a host-triple. Rather than expand to -L "" if llvm-config has not yet been built, add a dependency on the target llvm-config. When the target-triple is not a host-triple, the new LLVM_CONFIG_$(2) dependency should expand to nothing.
2015-03-16 23:13:36 -05:00
$$(LLVM_CONFIG_$(2)) \
mk: Remove extra whitespace before line continuation backslashes
2014-07-22 23:37:05 -05:00
$$(TSREQ$(1)_T_$(2)_H_$(3)) \
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
| $$(TLIB$(1)_T_$(2)_H_$(3))/
mk: Replace 'oxidize' with 'rustc'. Closes #13781
2014-05-21 00:14:38 -05:00
@$$(call E, rustc: $$(@D)/lib$(4))
Make build timestamp files robust in face of concurrent source modification. Strategy: If the end goal is to touch e.g. `stamp.std`, then we first touch `stamp.std.start_time` before doing anything else. Then when the receipe finishes, we touch `stamp.std` using the timestamp from `stamp.std.start_time` as the reference time, and remove `stamp.std.start_time`. Fix #6518.
2015-03-03 08:11:01 -06:00
@touch $$@.start_time
mk: Add space before line continuation backslash
2014-07-22 23:45:08 -05:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES, \
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
$$(dir $$@)$$(call CFG_LIB_GLOB_$(2),$(4)))
mk: Add space before line continuation backslash
2014-07-22 23:45:08 -05:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES, \
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
$$(dir $$@)$$(call CFG_RLIB_GLOB,$(4)))
mk: Fix native LLVM deps for cross-host builds We use a script called `mklldeps.py` to run `llvm-config` to generate a list of LLVM libraries and native dependencies needed by LLVM, but all cross-compiled LLVM builds were using the *host triple's* `llvm-config` instead of the *target's* `llvm-config`. This commit alters this to require the right `llvmdeps.rs` to be generated which will run the correct `llvm-config`.
2015-05-11 14:30:47 -05:00
$(Q)CFG_LLVM_LINKAGE_FILE=$$(LLVM_LINKAGE_PATH_$(2)) \
Don't use the same llvmdeps.rs for every host.
2014-11-25 17:28:49 -06:00
$$(subst @,,$$(STAGE$(1)_T_$(2)_H_$(3))) \
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$$(RUST_LIB_FLAGS_ST$(1)) \
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
-L "$$(RT_OUTPUT_DIR_$(2))" \
Avoid passing -L "" during cross-compilation. LLVM_LIBDIR_<triple> is only defined for host triples, not target triples. FWIW, the same is true for LLVM_STDCPP_RUSTFLAGS_<triple>, where we explicitly define it as empty when --enable-llvm-static-stdcpp is not specified, but it's still undefined for cross-compiled triples.
2015-03-12 21:24:59 -05:00
$$(LLVM_LIBDIR_RUSTFLAGS_$(2)) \
Avoid passing -L "" to rustc. Currently, target.mk passes -L "" when LLVM_STDCPP_LOCATION_$(2) is empty. This fixes #23287.
2015-03-12 06:09:12 -05:00
$$(LLVM_STDCPP_RUSTFLAGS_$(2)) \
alloc: Allow disabling jemalloc
2014-06-14 01:23:31 -05:00
$$(RUSTFLAGS_$(4)) \
plumbing to automatically run MIR for crates where it works; this serves as a poor man's unit test infrastructure until MIR is more built up
2015-08-18 17:02:14 -05:00
$$(RUSTFLAGS$(1)_$(4)) \
trans: Stop informing LLVM about dllexport Rust's current compilation model makes it impossible on Windows to generate one object file with a complete and final set of dllexport annotations. This is because when an object is generated the compiler doesn't actually know if it will later be included in a dynamic library or not. The compiler works around this today by flagging *everything* as dllexport, but this has the drawback of exposing too much. Thankfully there are alternate methods of specifying the exported surface area of a dll on Windows, one of which is passing a `*.def` file to the linker which lists all public symbols of the dynamic library. This commit removes all locations that add `dllexport` to LLVM variables and instead dynamically generates a `*.def` file which is passed to the linker. This file will include all the public symbols of the current object file as well as all upstream libraries, and the crucial aspect is that it's only used when generating a dynamic library. When generating an executable this file isn't generated, so all the symbols aren't exported from an executable. To ensure that statically included native libraries are reexported correctly, the previously added support for the `#[linked_from]` attribute is used to determine the set of FFI symbols that are exported from a dynamic library, and this is required to get the compiler to link correctly.
2015-07-28 19:19:08 -05:00
$$(RUSTFLAGS$(1)_$(4)_T_$(2)) \
rustc: Stop putting hashes in filenames by default The compiler will no longer insert a hash or version into a filename by default. Instead, all output is simply based off the crate name being compiled. For example, a crate name of `foo` would produce the following outputs: * bin => foo * rlib => libfoo.rlib * dylib => libfoo.{so,dylib} or foo.dll * staticlib => libfoo.a The old behavior has been moved behind a new codegen flag, `-C extra-filename=<hash>`. For example, with the "extra filename" of `bar` and a crate name of `foo`, the following outputs would be generated: * bin => foo (same old behavior) * rlib => libfoobar.rlib * dylib => libfoobar.{so,dylib} or foobar.dll * staticlib => libfoobar.a The makefiles have been altered to pass a hash by default to invocations of `rustc` so all installed rust libraries will have a hash in their filename. This is done because the standard libraries are intended to be installed into privileged directories such as /usr/local. Additionally, it involves very few build system changes! RFC: 0035-remove-crate-id [breaking-change]
2014-07-01 09:57:07 -05:00
--out-dir $$(@D) \
Register new snapshots Closes #15544
2014-07-09 12:57:01 -05:00
-C extra-filename=-$$(CFG_FILENAME_EXTRA) \
mk: Add `-C metadata` for compiling crates we ship This should re-enable all external builds of crates with the same name. Right now Cargo doesn't pass `-C metadata` for the top-level library being compiled, so if that library is called `libc`, for example, then it won't be able to link to the standard library which *also* has a `libc` library compiled without `-C metadata`. This can result in naming conflicts which need to be resolved. By passing `-C metadata` to the in-tree crates we ship it should add some extra salt to all symbol names to ensure that they don't collide.
2016-03-28 11:19:25 -05:00
-C metadata=$$(CFG_FILENAME_EXTRA) \
rustc: Stop putting hashes in filenames by default The compiler will no longer insert a hash or version into a filename by default. Instead, all output is simply based off the crate name being compiled. For example, a crate name of `foo` would produce the following outputs: * bin => foo * rlib => libfoo.rlib * dylib => libfoo.{so,dylib} or foo.dll * staticlib => libfoo.a The old behavior has been moved behind a new codegen flag, `-C extra-filename=<hash>`. For example, with the "extra filename" of `bar` and a crate name of `foo`, the following outputs would be generated: * bin => foo (same old behavior) * rlib => libfoobar.rlib * dylib => libfoobar.{so,dylib} or foobar.dll * staticlib => libfoobar.a The makefiles have been altered to pass a hash by default to invocations of `rustc` so all installed rust libraries will have a hash in their filename. This is done because the standard libraries are intended to be installed into privileged directories such as /usr/local. Additionally, it involves very few build system changes! RFC: 0035-remove-crate-id [breaking-change]
2014-07-01 09:57:07 -05:00
$$<
Make build timestamp files robust in face of concurrent source modification. Strategy: If the end goal is to touch e.g. `stamp.std`, then we first touch `stamp.std.start_time` before doing anything else. Then when the receipe finishes, we touch `stamp.std` using the timestamp from `stamp.std.start_time` as the reference time, and remove `stamp.std.start_time`. Fix #6518.
2015-03-03 08:11:01 -06:00
@touch -r $$@.start_time $$@ && rm $$@.start_time
mk: Add space before line continuation backslash
2014-07-22 23:45:08 -05:00
$$(call LIST_ALL_OLD_GLOB_MATCHES, \
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
$$(dir $$@)$$(call CFG_LIB_GLOB_$(2),$(4)))
mk: Add space before line continuation backslash
2014-07-22 23:45:08 -05:00
$$(call LIST_ALL_OLD_GLOB_MATCHES, \
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
$$(dir $$@)$$(call CFG_RLIB_GLOB,$(4)))
endef
# Macro for building any tool as part of the rust compilation process. Each
# tool is defined in crates.mk with a list of library dependencies as well as
# the source file for the tool. Building each tool will also be passed '--cfg
# <tool>' for usage in driver.rs
#
# This build rule is similar to the one found above, just tweaked for
# locations and things.
#
# $(1) - stage
# $(2) - target triple
# $(3) - host triple
# $(4) - name of the tool being built
define TARGET_TOOL
mk: Bootstrap from stable instead of snapshots This commit removes all infrastructure from the repository for our so-called snapshots to instead bootstrap the compiler from stable releases. Bootstrapping from a previously stable release is a long-desired feature of distros because they're not fans of downloading binary stage0 blobs from us. Additionally, this makes our own CI easier as we can decommission all of the snapshot builders and start having a regular cadence to when we update the stage0 compiler. A new `src/etc/get-stage0.py` script was added which shares some code with `src/bootstrap/bootstrap.py` to read a new file, `src/stage0.txt`, which lists the current stage0 compiler as well as cargo that we bootstrap from. This script will download the relevant `rustc` package an unpack it into `$target/stage0` as we do today. One problem of bootstrapping from stable releases is that we're not able to compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd). To overcome this we employ two strategies: * The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt` (enabled as a result of #32731) and exported by the build system. This enables nightly features in the compiler we download. * The standard library and compiler are pinned to a specific stage0, which doesn't change, so we're guaranteed that we'll continue compiling as we start from a known fixed source. The process for making a release will also need to be tweaked now to continue to cadence of bootstrapping from the previous release. This process looks like: 1. Merge `beta` to `stable` 2. Produce a new stable compiler. 3. Change `master` to bootstrap from this new stable compiler. 4. Merge `master` to `beta` 5. Produce a new beta compiler 6. Change `master` to bootstrap from this new beta compiler. Step 3 above should involve very few changes as `master` was previously bootstrapping from `beta` which is the same as `stable` at that point in time. Step 6, however, is where we benefit from removing lots of `#[cfg(stage0)]` and get to use new features. This also shouldn't slow the release too much as steps 1-5 requires little work other than waiting and step 6 just needs to happen at some point during a release cycle, it's not time sensitive. Closes #29555 Closes #29557
2016-04-13 13:18:35 -05:00
$$(TBIN$(1)_T_$(2)_H_$(3))/$(4)$$(X_$(2)): \
mk: Fix bootstrapping cross-hosts on beta The beta builds are currently failing, unfortunately, due to what is presumably some odd behavior with our makefiles. The wrong bootstrap key is being used to generate the stage1 cross-compiled libraries, which fails the build. Interestingly enough if the targets are directly specified as part of the build then it works just fine! Just a bare `make` fails... Instead of trying to understand what's happening in the makefiles instead just tweak how we configure the bootstrap key in a way that's more likely to work.
2016-05-23 15:45:26 -05:00
export RUSTC_BOOTSTRAP_KEY := $$(BOOTSTRAP_KEY$(1)_T_$(2)_H_$(3))
mk: Remove extra whitespace before line continuation backslashes
2014-07-22 23:37:05 -05:00
$$(TBIN$(1)_T_$(2)_H_$(3))/$(4)$$(X_$(2)): \
$$(TOOL_SOURCE_$(4)) \
$$(TOOL_INPUTS_$(4)) \
$$(foreach dep,$$(TOOL_DEPS_$(4)), \
$$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$$(dep)) \
$$(TSREQ$(1)_T_$(2)_H_$(3)) \
mk/target: fix typo so we depend on the correct directory Without this, if we we're using a non-standard host libdir, the target bindir would not exist (and rustc would fail to write to the non-existent directory).
2014-11-18 15:32:03 -06:00
| $$(TBIN$(1)_T_$(2)_H_$(3))/
mk: Replace 'oxidize' with 'rustc'. Closes #13781
2014-05-21 00:14:38 -05:00
@$$(call E, rustc: $$@)
pass stdc++ library path after LVVM library path under openbsd, the library path of libstdc++ need to be explicit (due to the fact the default linker `cc` is gcc-4.2, and not gcc-4.9). but when a recent LLVM is installed, rustc compilation pikes the bad LLVM version (which live in /usr/local/lib, which is same directory of libestdc++.so for gcc-4.9). this patch move the libstdc++ path from RUST_FLAGS_<target> to special variable, and use it *after* LLVM_LIBDIR_RUSTFLAGS_<target> in arguments.
2015-11-11 13:16:17 -06:00
$$(STAGE$(1)_T_$(2)_H_$(3)) \
Better support for `--llvm-root`. This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with `LD_LIBRARY_PATH` etc).
2015-08-21 23:43:56 -05:00
$$(LLVM_LIBDIR_RUSTFLAGS_$(2)) \
pass stdc++ library path after LVVM library path under openbsd, the library path of libstdc++ need to be explicit (due to the fact the default linker `cc` is gcc-4.2, and not gcc-4.9). but when a recent LLVM is installed, rustc compilation pikes the bad LLVM version (which live in /usr/local/lib, which is same directory of libestdc++.so for gcc-4.9). this patch move the libstdc++ path from RUST_FLAGS_<target> to special variable, and use it *after* LLVM_LIBDIR_RUSTFLAGS_<target> in arguments.
2015-11-11 13:16:17 -06:00
-o $$@ $$< --cfg $(4)
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
Lots of build system cleanup and documentation This splits mk/stageN.mk into host.mk and target.mk and makes the build rules somewhat simpler - there's no more building from stageN into stageN+1; instead we always build from stageN(host) to stageN(target) then promote from stageN(target) to stageN+1(host). Add a big honkin explaination right at the top of Makefile.in
2011-10-01 22:12:08 -05:00
Don't use GCC's startup objects (crtbegin.o/crtend.o); build and use our own (for now on for -windows-gnu target only). Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory. Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.
2015-10-18 16:32:50 -05:00
# Macro for building runtime startup/shutdown object files;
# these are Rust's equivalent of crti.o, crtn.o
#
# $(1) - stage
# $(2) - target triple
# $(3) - host triple
Use `gcc -print-file-name` for finding C runtime startup objects: reverted changes in configure, refactored target.mk
2015-10-21 01:08:00 -05:00
# $(4) - object basename
Don't use GCC's startup objects (crtbegin.o/crtend.o); build and use our own (for now on for -windows-gnu target only). Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory. Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.
2015-10-18 16:32:50 -05:00
define TARGET_RUSTRT_STARTUP_OBJ
Use `gcc -print-file-name` for finding C runtime startup objects: reverted changes in configure, refactored target.mk
2015-10-21 01:08:00 -05:00
$$(TLIB$(1)_T_$(2)_H_$(3))/$(4).o: \
Don't use GCC's startup objects (crtbegin.o/crtend.o); build and use our own (for now on for -windows-gnu target only). Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory. Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.
2015-10-18 16:32:50 -05:00
$(S)src/rtstartup/$(4).rs \
$$(TLIB$(1)_T_$(2)_H_$(3))/stamp.core \
Revert "mk: fix some undefined variable warnings" This reverts commit d03712977d7c913044f2b863269c4491d7fa7c36.
2016-02-02 01:27:04 -06:00
$$(HSREQ$(1)_T_$(2)_H_$(3)) \
Don't use GCC's startup objects (crtbegin.o/crtend.o); build and use our own (for now on for -windows-gnu target only). Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory. Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.
2015-10-18 16:32:50 -05:00
| $$(TBIN$(1)_T_$(2)_H_$(3))/
@$$(call E, rustc: $$@)
$$(STAGE$(1)_T_$(2)_H_$(3)) --emit=obj -o $$@ $$<
Revert "mk: fix some undefined variable warnings" This reverts commit d03712977d7c913044f2b863269c4491d7fa7c36.
2016-02-02 01:27:04 -06:00
ifeq ($$(CFG_RUSTRT_HAS_STARTUP_OBJS_$(2)), 1)
Don't use GCC's startup objects (crtbegin.o/crtend.o); build and use our own (for now on for -windows-gnu target only). Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory. Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.
2015-10-18 16:32:50 -05:00
# Add dependencies on Rust startup objects to all crates that depend on core.
# This ensures that they are built after core (since they depend on it),
# but before everything else (since they are needed for linking dylib crates).
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
$$(foreach crate, $$(TARGET_CRATES_$(2)), \
Don't use GCC's startup objects (crtbegin.o/crtend.o); build and use our own (for now on for -windows-gnu target only). Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory. Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.
2015-10-18 16:32:50 -05:00
$$(if $$(findstring core,$$(DEPS_$$(crate))), \
Use `gcc -print-file-name` for finding C runtime startup objects: reverted changes in configure, refactored target.mk
2015-10-21 01:08:00 -05:00
$$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$$(crate))) : $$(TLIB$(1)_T_$(2)_H_$(3))/$(4).o
Remove STARTUP_OBJS from Makefile deps for non win-gnu targets. The `rsbegin.o` and `rsend.o` build products should not be generated on non WinGnu platforms. This is another path to resolving #30063 for non win-gnu targets. (And it won't require a snapshot, unlike PR #30208.)
2015-12-08 07:56:22 -06:00
endif
Use `gcc -print-file-name` for finding C runtime startup objects: reverted changes in configure, refactored target.mk
2015-10-21 01:08:00 -05:00
Don't use GCC's startup objects (crtbegin.o/crtend.o); build and use our own (for now on for -windows-gnu target only). Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory. Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.
2015-10-18 16:32:50 -05:00
endef
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
# Every recipe in RUST_TARGET_STAGE_N outputs to $$(TLIB$(1)_T_$(2)_H_$(3),
small cleanup of previous commit with mucho comments.
2013-08-31 17:53:56 -05:00
# a directory that can be cleaned out during the middle of a run of
# the get-snapshot.py script. Therefore, every recipe needs to have
# an order-only dependency either on $(SNAPSHOT_RUSTC_POST_CLEANUP) or
# on $$(TSREQ$(1)_T_$(2)_H_$(3)), to ensure that no products will be
# put into the target area until after the get-snapshot.py script has
# had its chance to clean it out; otherwise the other products will be
Fix some typos
2015-03-28 10:09:51 -05:00
# inadvertently included in the clean out.
support for GNU configure syntax
2013-10-21 04:18:21 -05:00
SNAPSHOT_RUSTC_POST_CLEANUP=$(HBIN0_H_$(CFG_BUILD))/rustc$(X_$(CFG_BUILD))
Fix for make -j race from #9531 injected by cleanup in b1a22518f0c687db.
2013-09-26 16:56:53 -05:00
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
define TARGET_HOST_RULES
rt: Build __morestack as a static library and copy it to the right places
2011-11-28 19:23:13 -06:00
mk: Bootstrap from stable instead of snapshots This commit removes all infrastructure from the repository for our so-called snapshots to instead bootstrap the compiler from stable releases. Bootstrapping from a previously stable release is a long-desired feature of distros because they're not fans of downloading binary stage0 blobs from us. Additionally, this makes our own CI easier as we can decommission all of the snapshot builders and start having a regular cadence to when we update the stage0 compiler. A new `src/etc/get-stage0.py` script was added which shares some code with `src/bootstrap/bootstrap.py` to read a new file, `src/stage0.txt`, which lists the current stage0 compiler as well as cargo that we bootstrap from. This script will download the relevant `rustc` package an unpack it into `$target/stage0` as we do today. One problem of bootstrapping from stable releases is that we're not able to compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd). To overcome this we employ two strategies: * The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt` (enabled as a result of #32731) and exported by the build system. This enables nightly features in the compiler we download. * The standard library and compiler are pinned to a specific stage0, which doesn't change, so we're guaranteed that we'll continue compiling as we start from a known fixed source. The process for making a release will also need to be tweaked now to continue to cadence of bootstrapping from the previous release. This process looks like: 1. Merge `beta` to `stable` 2. Produce a new stable compiler. 3. Change `master` to bootstrap from this new stable compiler. 4. Merge `master` to `beta` 5. Produce a new beta compiler 6. Change `master` to bootstrap from this new beta compiler. Step 3 above should involve very few changes as `master` was previously bootstrapping from `beta` which is the same as `stable` at that point in time. Step 6, however, is where we benefit from removing lots of `#[cfg(stage0)]` and get to use new features. This also shouldn't slow the release too much as steps 1-5 requires little work other than waiting and step 6 just needs to happen at some point during a release cycle, it's not time sensitive. Closes #29555 Closes #29557
2016-04-13 13:18:35 -05:00
$$(TLIB$(1)_T_$(2)_H_$(3))/: $$(SNAPSHOT_RUSTC_POST_CLEANUP)
mkdir -p $$@
$$(TBIN$(1)_T_$(2)_H_$(3))/: $$(SNAPSHOT_RUSTC_POST_CLEANUP)
Fix syntax: had to use escaped $$ to have an effect after first expansion.
2013-05-04 03:57:56 -05:00
mkdir -p $$@
Make build products depend on their target directories. This is an attempt to address Issue #3326 by adding [*order-only*][1] prerequsites of each build product on the directory where it is to go. It is important that the prerequisites be order-only, since the timestamp on a parent directory is not relevant to whether a product is out of date; the parent directory merely needs to exist. (This use case of generating target directories was provided as an [example][2] of how order-only prequisites are used.) [1]: http://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html [2]: http://www.kolpackov.net/pipermail/notes/2004-January/000001.html
2013-05-03 11:53:47 -05:00
mk: Add support for musl-based builds This commit adds support to the makefiles, configuration script, and build system to understand MUSL. This is broken up into a few parts: * Any target of the form `*-musl` requires the `--musl-root` option to `./configure` which will indicate the root of the MUSL installation. It is also expected that there is a libunwind build inside of that installation built against that MUSL. * Objects from MUSL are copied into the build tree for Rust to be statically linked into the appropriate Rust library. * Objects for binary startup and shutdown are included in each Rust installation by default for MUSL. This requires MUSL to only be installed on the machine compiling rust. Only a linker will be necessary for compiling against MUSL on a target machine. Eventually a MUSL and/or libunwind build may be integrated by default into the build but for now they are just always assumed to exist externally.
2015-04-21 17:42:05 -05:00
$$(TLIB$(1)_T_$(2)_H_$(3))/%: $$(RT_OUTPUT_DIR_$(2))/% \
mk: Bootstrap from stable instead of snapshots This commit removes all infrastructure from the repository for our so-called snapshots to instead bootstrap the compiler from stable releases. Bootstrapping from a previously stable release is a long-desired feature of distros because they're not fans of downloading binary stage0 blobs from us. Additionally, this makes our own CI easier as we can decommission all of the snapshot builders and start having a regular cadence to when we update the stage0 compiler. A new `src/etc/get-stage0.py` script was added which shares some code with `src/bootstrap/bootstrap.py` to read a new file, `src/stage0.txt`, which lists the current stage0 compiler as well as cargo that we bootstrap from. This script will download the relevant `rustc` package an unpack it into `$target/stage0` as we do today. One problem of bootstrapping from stable releases is that we're not able to compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd). To overcome this we employ two strategies: * The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt` (enabled as a result of #32731) and exported by the build system. This enables nightly features in the compiler we download. * The standard library and compiler are pinned to a specific stage0, which doesn't change, so we're guaranteed that we'll continue compiling as we start from a known fixed source. The process for making a release will also need to be tweaked now to continue to cadence of bootstrapping from the previous release. This process looks like: 1. Merge `beta` to `stable` 2. Produce a new stable compiler. 3. Change `master` to bootstrap from this new stable compiler. 4. Merge `master` to `beta` 5. Produce a new beta compiler 6. Change `master` to bootstrap from this new beta compiler. Step 3 above should involve very few changes as `master` was previously bootstrapping from `beta` which is the same as `stable` at that point in time. Step 6, however, is where we benefit from removing lots of `#[cfg(stage0)]` and get to use new features. This also shouldn't slow the release too much as steps 1-5 requires little work other than waiting and step 6 just needs to happen at some point during a release cycle, it's not time sensitive. Closes #29555 Closes #29557
2016-04-13 13:18:35 -05:00
$$(SNAPSHOT_RUSTC_POST_CLEANUP) \
| $$(TLIB$(1)_T_$(2)_H_$(3))/
mk: Add the ability to depend on native LLVM tools The compiler will require that `llvm-ar.exe` be available for MSVC-targeting builds (more comments on this soon), so this commit adds support for targets to depend on LLVM tools. The `core` library for MSVC depends on `llvm-ar.exe` which will be copied into place for the target before the compiler starts to run. Note that these targets all depend on `llvm-config.exe` to ensure that they're built before they're attempted to be copied.
2015-05-11 16:14:11 -05:00
@$$(call E, cp: $$@)
$$(Q)cp $$< $$@
build: Add USE_SNAPSHOT_STDLIB. Set to 1
2012-05-22 13:40:46 -05:00
endef
mk: Remove extra whitespace before line continuation backslashes
2014-07-22 23:37:05 -05:00
$(foreach source,$(CFG_HOST), \
$(foreach target,$(CFG_TARGET), \
$(eval $(call TARGET_HOST_RULES,0,$(target),$(source))) \
$(eval $(call TARGET_HOST_RULES,1,$(target),$(source))) \
$(eval $(call TARGET_HOST_RULES,2,$(target),$(source))) \
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
$(eval $(call TARGET_HOST_RULES,3,$(target),$(source)))))
# In principle, each host can build each target for both libs and tools
mk: Remove extra whitespace before line continuation backslashes
2014-07-22 23:37:05 -05:00
$(foreach crate,$(CRATES), \
$(foreach source,$(CFG_HOST), \
$(foreach target,$(CFG_TARGET), \
$(eval $(call RUST_TARGET_STAGE_N,0,$(target),$(source),$(crate))) \
$(eval $(call RUST_TARGET_STAGE_N,1,$(target),$(source),$(crate))) \
$(eval $(call RUST_TARGET_STAGE_N,2,$(target),$(source),$(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
$(eval $(call RUST_TARGET_STAGE_N,3,$(target),$(source),$(crate))))))
mk: Remove extra whitespace before line continuation backslashes
2014-07-22 23:37:05 -05:00
$(foreach host,$(CFG_HOST), \
$(foreach target,$(CFG_TARGET), \
$(foreach stage,$(STAGES), \
$(foreach tool,$(TOOLS), \
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
$(eval $(call TARGET_TOOL,$(stage),$(target),$(host),$(tool)))))))
Don't use GCC's startup objects (crtbegin.o/crtend.o); build and use our own (for now on for -windows-gnu target only). Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory. Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.
2015-10-18 16:32:50 -05:00
$(foreach host,$(CFG_HOST), \
$(foreach target,$(CFG_TARGET), \
$(foreach stage,$(STAGES), \
Clean up some "suspicious" whitespace in target.mk Emacs warns that makefile lines that start with spaces followed by tabs are "suspicious". These were harmless since they were continuation lines, but getting rid of the warning is nice and this version looks better.
2015-11-13 14:01:07 -06:00
$(foreach obj,rsbegin rsend, \
$(eval $(call TARGET_RUSTRT_STARTUP_OBJ,$(stage),$(target),$(host),$(obj)))))))
Reference in New Issue Copy Permalink