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

263 lines
9.9 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
Deny common lints by default for lib{std,extra}
2013-06-25 19:02:03 -05:00
# The standard libraries should be held up to a higher standard than any old
# code, make sure that these common warnings are denied by default. These can
Allow stage0 warnings
2013-10-16 13:27:24 -05:00
# be overridden during development temporarily. For stage0, we allow warnings
# which may be bugs in stage0 (should be fixed in stage1+)
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_ST0 += -W warnings
RUST_LIB_FLAGS_ST1 += -D warnings
RUST_LIB_FLAGS_ST2 += -D warnings
Deny common lints by default for lib{std,extra}
2013-06-25 19:02:03 -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
# 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)) \
$$(foreach dep,$$(RUST_DEPS_$(4)), \
$$(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)), \
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
$$(RT_OUTPUT_DIR_$(2))/$$(dep)) \
$$(foreach dep,$$(NATIVE_TOOL_DEPS_$(4)_T_$(2)), \
mk: Generate a .def file for rustc_llvm on MSVC Windows needs explicit exports of functions from DLLs but LLVM does not mention any of its symbols as being export-able from a DLL. The compiler, however, relies on being able to use LLVM symbols across DLL boundaries so we need to force many of LLVM's symbols to be exported from `rustc_llvm.dll`. This commit adds support for generation of a `rustc_llvm.def` file which is passed along to the linker when generating `rustc_llvm.dll` which should keep all these symbols exportable and usable.
2015-05-11 17:49:30 -05:00
$$(TBIN$(1)_T_$(3)_H_$(3))/$$(dep)) \
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
$$(CUSTOM_DEPS$(1)_$(4)_T_$(2))
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)))))))
# 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: 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)) \
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) \
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: 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: $$@)
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
$$(STAGE$(1)_T_$(2)_H_$(3)) -o $$@ $$< --cfg $(4)
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
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
Fix another goof: consistently use parent directory of target for rule. (I wonder if there's a better way to write this in the rule itself; i.e. something like `$$(dirname $$@)`. But for now this will do.)
2013-05-04 05:46:11 -05:00
$$(TBIN$(1)_T_$(2)_H_$(3))/:
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
$$(TLIB$(1)_T_$(2)_H_$(3))/:
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))/% \
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))/ $$(SNAPSHOT_RUSTC_POST_CLEANUP)
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 $$< $$@
$$(TBIN$(1)_T_$(2)_H_$(3))/%: $$(CFG_LLVM_INST_DIR_$(2))/bin/% \
| $$(TBIN$(1)_T_$(2)_H_$(3))/ $$(SNAPSHOT_RUSTC_POST_CLEANUP)
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
@$$(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)))))))
mk: Fix MSVC bootstrapping itself Now that MSVC support has landed in the most recent nightlies we can now have MSVC bootstrap itself without going through a GNU compiler first. Unfortunately, however, the bootstrap currently fails due to the compiler not being able to find the llvm-ar.exe tool during the stage0 libcore compile. The compiler cannot find this tool because it's looking inside a directory that does not exist: $SYSROOT/rustlib/x86_64-pc-windows-gnu/bin The `gnu` on this triple is because the bootstrap compiler's host architecture is GNU. The build system, however, only arranges for the llvm-ar.exe tool to be available in this location: $SYSROOT/rustlib/x86_64-pc-windows-msvc/bin To resolve this discrepancy, the build system has been modified to understand triples that are bootstrapped from another triple, and in this case copy the native tools to the right location.
2015-05-27 19:30:57 -05:00
# We have some triples which are bootstrapped from other triples, and this means
# that we need to fixup some of the native tools that a triple depends on.
#
# For example, MSVC requires the llvm-ar.exe executable to manage archives, but
# it bootstraps from the GNU Windows triple. This means that the compiler will
# add this directory to PATH when executing new processes:
#
# $SYSROOT/rustlib/x86_64-pc-windows-gnu/bin
#
# Unfortunately, however, the GNU triple is not known about in stage0, so the
# tools are actually located in:
#
# $SYSROOT/rustlib/x86_64-pc-windows-msvc/bin
#
# To remedy this problem, the rules below copy all native tool dependencies into
# the bootstrap triple's location in stage 0 so the bootstrap compiler can find
# the right sets of tools. Later stages (1+) will have the right host triple for
# the compiler, so there's no need to worry there.
#
# $(1) - stage
# $(2) - triple that's being used as host/target
# $(3) - triple snapshot is built for
# $(4) - crate
# $(5) - tool
trans: Specify `archive_format` for MSVC This means that we no longer need to ship the `llvm-ar.exe` binary in the MSVC distribution, and after a snapshot we can remove a good bit of logic from the makefiles!
2015-08-04 11:08:07 -05:00
#
# FIXME(stage0): remove this and all other relevant support in the makefiles
# after a snapshot is made
mk: Fix MSVC bootstrapping itself Now that MSVC support has landed in the most recent nightlies we can now have MSVC bootstrap itself without going through a GNU compiler first. Unfortunately, however, the bootstrap currently fails due to the compiler not being able to find the llvm-ar.exe tool during the stage0 libcore compile. The compiler cannot find this tool because it's looking inside a directory that does not exist: $SYSROOT/rustlib/x86_64-pc-windows-gnu/bin The `gnu` on this triple is because the bootstrap compiler's host architecture is GNU. The build system, however, only arranges for the llvm-ar.exe tool to be available in this location: $SYSROOT/rustlib/x86_64-pc-windows-msvc/bin To resolve this discrepancy, the build system has been modified to understand triples that are bootstrapped from another triple, and in this case copy the native tools to the right location.
2015-05-27 19:30:57 -05:00
define MOVE_TOOLS_TO_SNAPSHOT_HOST_DIR
ifneq (,$(3))
$$(TLIB$(1)_T_$(2)_H_$(2))/stamp.$(4): $$(HLIB$(1)_H_$(2))/rustlib/$(3)/bin/$(5)
$$(HLIB$(1)_H_$(2))/rustlib/$(3)/bin/$(5): $$(TBIN$(1)_T_$(2)_H_$(2))/$(5)
mkdir -p $$(@D)
cp $$< $$@
endif
endef
$(foreach target,$(CFG_TARGET), \
$(foreach crate,$(CRATES), \
$(foreach tool,$(NATIVE_TOOL_DEPS_$(crate)_T_$(target)), \
$(eval $(call MOVE_TOOLS_TO_SNAPSHOT_HOST_DIR,0,$(target),$(BOOTSTRAP_FROM_$(target)),$(crate),$(tool))))))
mk: Add support for i686-pc-windows-msvc This commit modifies the configure script and our makefiles to support building 32-bit MSVC targets. The MSVC toolchain is now parameterized over whether it can produce a 32-bit or 64-bit binary. The configure script was updated to export more variables at configure time, and the makefiles were rejiggered to selectively reexport the relevant environment variables for the applicable targets they're going to run for.
2015-06-25 17:30:00 -05:00
# For MSVC targets we need to set up some environment variables for the linker
# to work correctly when building Rust crates. These two variables are:
#
# - LIB tells the linker the default search path for finding system libraries,
# for example kernel32.dll
# - PATH needs to be modified to ensure that MSVC's link.exe is first in the
# path instead of MinGW's /usr/bin/link.exe (entirely unrelated)
#
# The values for these variables are detected by the configure script.
trans: Specify `archive_format` for MSVC This means that we no longer need to ship the `llvm-ar.exe` binary in the MSVC distribution, and after a snapshot we can remove a good bit of logic from the makefiles!
2015-08-04 11:08:07 -05:00
#
# FIXME(stage0): remove this and all other relevant support in the makefiles
# after a snapshot is made
mk: Add support for i686-pc-windows-msvc This commit modifies the configure script and our makefiles to support building 32-bit MSVC targets. The MSVC toolchain is now parameterized over whether it can produce a 32-bit or 64-bit binary. The configure script was updated to export more variables at configure time, and the makefiles were rejiggered to selectively reexport the relevant environment variables for the applicable targets they're going to run for.
2015-06-25 17:30:00 -05:00
define SETUP_LIB_MSVC_ENV_VARS
ifeq ($$(findstring msvc,$(2)),msvc)
$$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$(4): \
export LIB := $$(CFG_MSVC_LIB_PATH_$$(HOST_$(2)))
$$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$(4): \
export PATH := $$(CFG_MSVC_BINDIR_$$(HOST_$(2))):$$(PATH)
endif
endef
define SETUP_TOOL_MSVC_ENV_VARS
ifeq ($$(findstring msvc,$(2)),msvc)
$$(TBIN$(1)_T_$(2)_H_$(3))/$(4)$$(X_$(2)): \
export LIB := $$(CFG_MSVC_LIB_PATH_$$(HOST_$(2)))
$$(TBIN$(1)_T_$(2)_H_$(3))/$(4)$$(X_$(2)): \
export PATH := $$(CFG_MSVC_BINDIR_$$(HOST_$(2))):$$(PATH)
endif
endef
$(foreach host,$(CFG_HOST), \
$(foreach target,$(CFG_TARGET), \
msvc: Lookup linker in windows registry This commit alters the compiler to no longer "just run link.exe" but instead probe the system's registry to find where the linker is located. The default library search path (normally found through LIB) is also found through the registry. This also brings us in line with the default behavior of Clang, and much of the logic of where to look for information is copied over from Clang as well. Finally, this commit removes the makefile logic for updating the environment variables for the compiler, except for stage0 where it's still necessary. The motivation for this change is rooted in two positions: * Not having to set up these environment variables is much less hassle both for the bootstrap and for running the compiler itself. This means that the compiler can be run outside of VS shells and be run inside of cmd.exe or a MSYS shell. * When dealing with cross compilation, there's not actually a set of environment variables that can be set for the compiler. This means, for example, if a Cargo compilation is targeting 32-bit from 64-bit you can't actually set up one set of environment variables. Having the compiler deal with the logic instead is generally much more convenient!
2015-06-30 01:16:24 -05:00
$(foreach crate,$(CRATES), \
$(eval $(call SETUP_LIB_MSVC_ENV_VARS,0,$(target),$(host),$(crate))))))
mk: Add support for i686-pc-windows-msvc This commit modifies the configure script and our makefiles to support building 32-bit MSVC targets. The MSVC toolchain is now parameterized over whether it can produce a 32-bit or 64-bit binary. The configure script was updated to export more variables at configure time, and the makefiles were rejiggered to selectively reexport the relevant environment variables for the applicable targets they're going to run for.
2015-06-25 17:30:00 -05:00
$(foreach host,$(CFG_HOST), \
$(foreach target,$(CFG_TARGET), \
msvc: Lookup linker in windows registry This commit alters the compiler to no longer "just run link.exe" but instead probe the system's registry to find where the linker is located. The default library search path (normally found through LIB) is also found through the registry. This also brings us in line with the default behavior of Clang, and much of the logic of where to look for information is copied over from Clang as well. Finally, this commit removes the makefile logic for updating the environment variables for the compiler, except for stage0 where it's still necessary. The motivation for this change is rooted in two positions: * Not having to set up these environment variables is much less hassle both for the bootstrap and for running the compiler itself. This means that the compiler can be run outside of VS shells and be run inside of cmd.exe or a MSYS shell. * When dealing with cross compilation, there's not actually a set of environment variables that can be set for the compiler. This means, for example, if a Cargo compilation is targeting 32-bit from 64-bit you can't actually set up one set of environment variables. Having the compiler deal with the logic instead is generally much more convenient!
2015-06-30 01:16:24 -05:00
$(foreach tool,$(TOOLS), \
$(eval $(call SETUP_TOOL_MSVC_ENV_VARS,0,$(target),$(host),$(tool))))))
Reference in New Issue Copy Permalink