mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
80991bb578
rust/mk/host.mk

168 lines
6.3 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.
basic builds function
2011-11-21 15:11:40 -06:00
# CP_HOST_STAGE_N template: arg 1 is the N we're promoting *from*, arg
# 2 is N+1. Must be invoked to promote target artifacts to host
# artifacts for stage 1-3 (stage0 host artifacts come from the
# snapshot). Arg 3 is the triple we're copying FROM and arg 4 is the
# triple we're copying TO.
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
#
# The easiest way to read this template is to assume we're promoting
# stage1 to stage2 and mentally gloss $(1) as 1, $(2) as 2.
basic builds function
2011-11-21 15:11:40 -06:00
define CP_HOST_STAGE_N
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
# Host libraries and executables (stage$(2)/bin/rustc and its runtime needs)
mk: cleanup - lib and executable suffix handling
2013-03-02 06:25:12 -06:00
# Note: $(3) and $(4) are both the same!
$$(HBIN$(2)_H_$(4))/rustc$$(X_$(4)): \
$$(TBIN$(1)_T_$(4)_H_$(3))/rustc$$(X_$(4)) \
$$(HLIB$(2)_H_$(4))/$(CFG_RUNTIME_$(4)) \
$$(HLIB$(2)_H_$(4))/$(CFG_RUSTLLVM_$(4)) \
$$(HLIB$(2)_H_$(4))/$(CFG_LIBRUSTC_$(4)) \
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
$$(HSTDLIB_DEFAULT$(2)_H_$(4)) \
libstd: Rename libcore to libstd and libstd to libextra; update makefiles. This only changes the directory names; it does not change the "real" metadata names.
2013-05-17 12:45:09 -05:00
$$(HEXTRALIB_DEFAULT$(2)_H_$(4)) \
Move rust's uv implementation to its own crate There are a few reasons that this is a desirable move to take: 1. Proof of concept that a third party event loop is possible 2. Clear separation of responsibility between rt::io and the uv-backend 3. Enforce in the future that the event loop is "pluggable" and replacable Here's a quick summary of the points of this pull request which make this possible: * Two new lang items were introduced: event_loop, and event_loop_factory. The idea of a "factory" is to define a function which can be called with no arguments and will return the new event loop as a trait object. This factory is emitted to the crate map when building an executable. The factory doesn't have to exist, and when it doesn't then an empty slot is in the crate map and a basic event loop with no I/O support is provided to the runtime. * When building an executable, then the rustuv crate will be linked by default (providing a default implementation of the event loop) via a similar method to injecting a dependency on libstd. This is currently the only location where the rustuv crate is ever linked. * There is a new #[no_uv] attribute (implied by #[no_std]) which denies implicitly linking to rustuv by default Closes #5019
2013-10-22 17:13:18 -05:00
$$(HLIBRUSTUV_DEFAULT$(2)_H_$(4)) \
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
| $$(HBIN$(2)_H_$(4))/
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
@$$(call E, cp: $$@)
$$(Q)cp $$< $$@
mk: cleanup - lib and executable suffix handling
2013-03-02 06:25:12 -06:00
$$(HLIB$(2)_H_$(4))/$(CFG_LIBRUSTC_$(4)): \
$$(TLIB$(1)_T_$(4)_H_$(3))/$(CFG_LIBRUSTC_$(4)) \
$$(HLIB$(2)_H_$(4))/$(CFG_LIBSYNTAX_$(4)) \
$$(HLIB$(2)_H_$(4))/$(CFG_RUNTIME_$(4)) \
$$(HLIB$(2)_H_$(4))/$(CFG_RUSTLLVM_$(4)) \
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
$$(HSTDLIB_DEFAULT$(2)_H_$(4)) \
libstd: Rename libcore to libstd and libstd to libextra; update makefiles. This only changes the directory names; it does not change the "real" metadata names.
2013-05-17 12:45:09 -05:00
$$(HEXTRALIB_DEFAULT$(2)_H_$(4)) \
Move rust's uv implementation to its own crate There are a few reasons that this is a desirable move to take: 1. Proof of concept that a third party event loop is possible 2. Clear separation of responsibility between rt::io and the uv-backend 3. Enforce in the future that the event loop is "pluggable" and replacable Here's a quick summary of the points of this pull request which make this possible: * Two new lang items were introduced: event_loop, and event_loop_factory. The idea of a "factory" is to define a function which can be called with no arguments and will return the new event loop as a trait object. This factory is emitted to the crate map when building an executable. The factory doesn't have to exist, and when it doesn't then an empty slot is in the crate map and a basic event loop with no I/O support is provided to the runtime. * When building an executable, then the rustuv crate will be linked by default (providing a default implementation of the event loop) via a similar method to injecting a dependency on libstd. This is currently the only location where the rustuv crate is ever linked. * There is a new #[no_uv] attribute (implied by #[no_std]) which denies implicitly linking to rustuv by default Closes #5019
2013-10-22 17:13:18 -05:00
$$(HLIBRUSTUV_DEFAULT$(2)_H_$(4)) \
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
| $$(HLIB$(2)_H_$(4))/
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
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
@$$(call E, cp: $$@)
Fix #3225: Incorporate feedback from Graydon. Namely, switched in many places to using GNU make provided functions for directory listing and text processing, rather than spawning a shell process to do that work. In the process of the revision, learned about Target-specific variables, which were very applicable to INSTALL_LIB (which, on a per-recipe basis, was always receiving the same actual arguments for its first two formal parameters in every invocation). http://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html (We might be able to make use of those in future refactorings.) ---- Also adds a cleanup pass to get-snapshot.py as well, since the same problem arises when we unpack libraries from the snapshot archive into a build directory with a prior snapshot's artifacts. (I put this step into the python script rather than the makefile because I wanted to delay the cleanup pass until after we have at least successfully downloaded the tarball. That way, if the download fails, you should not destroy the previous unarchived snapshot libraries and build products.) ---- Also reverted whitespace changes to minimize diff. I plan to put them back in in a dedicated commit elsewhere.
2013-07-08 11:35:47 -05:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBRUSTC_GLOB_$(4)),$$(notdir $$@))
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
$$(Q)cp $$< $$@
mk: cleanup - lib and executable suffix handling
2013-03-02 06:25:12 -06:00
$$(Q)cp -R $$(TLIB$(1)_T_$(4)_H_$(3))/$(LIBRUSTC_GLOB_$(4)) \
$(wildcard $$(TLIB$(1)_T_$(4)_H_$(3))/$(LIBRUSTC_DSYM_GLOB_$(4))) \
rustc: build versioned library with hash in its name Also updated build to install versioned libraries and added a few missing actions for `make clean`.
2011-12-02 10:51:59 -06:00
$$(HLIB$(2)_H_$(4))
Fix #3225: Incorporate feedback from Graydon. Namely, switched in many places to using GNU make provided functions for directory listing and text processing, rather than spawning a shell process to do that work. In the process of the revision, learned about Target-specific variables, which were very applicable to INSTALL_LIB (which, on a per-recipe basis, was always receiving the same actual arguments for its first two formal parameters in every invocation). http://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html (We might be able to make use of those in future refactorings.) ---- Also adds a cleanup pass to get-snapshot.py as well, since the same problem arises when we unpack libraries from the snapshot archive into a build directory with a prior snapshot's artifacts. (I put this step into the python script rather than the makefile because I wanted to delay the cleanup pass until after we have at least successfully downloaded the tarball. That way, if the download fails, you should not destroy the previous unarchived snapshot libraries and build products.) ---- Also reverted whitespace changes to minimize diff. I plan to put them back in in a dedicated commit elsewhere.
2013-07-08 11:35:47 -05:00
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBRUSTC_GLOB_$(4)),$$(notdir $$@))
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
mk: cleanup - lib and executable suffix handling
2013-03-02 06:25:12 -06:00
$$(HLIB$(2)_H_$(4))/$(CFG_LIBSYNTAX_$(4)): \
$$(TLIB$(1)_T_$(4)_H_$(3))/$(CFG_LIBSYNTAX_$(4)) \
$$(HLIB$(2)_H_$(4))/$(CFG_RUNTIME_$(4)) \
$$(HLIB$(2)_H_$(4))/$(CFG_RUSTLLVM_$(4)) \
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
$$(HSTDLIB_DEFAULT$(2)_H_$(4)) \
libstd: Rename libcore to libstd and libstd to libextra; update makefiles. This only changes the directory names; it does not change the "real" metadata names.
2013-05-17 12:45:09 -05:00
$$(HEXTRALIB_DEFAULT$(2)_H_$(4)) \
Move rust's uv implementation to its own crate There are a few reasons that this is a desirable move to take: 1. Proof of concept that a third party event loop is possible 2. Clear separation of responsibility between rt::io and the uv-backend 3. Enforce in the future that the event loop is "pluggable" and replacable Here's a quick summary of the points of this pull request which make this possible: * Two new lang items were introduced: event_loop, and event_loop_factory. The idea of a "factory" is to define a function which can be called with no arguments and will return the new event loop as a trait object. This factory is emitted to the crate map when building an executable. The factory doesn't have to exist, and when it doesn't then an empty slot is in the crate map and a basic event loop with no I/O support is provided to the runtime. * When building an executable, then the rustuv crate will be linked by default (providing a default implementation of the event loop) via a similar method to injecting a dependency on libstd. This is currently the only location where the rustuv crate is ever linked. * There is a new #[no_uv] attribute (implied by #[no_std]) which denies implicitly linking to rustuv by default Closes #5019
2013-10-22 17:13:18 -05:00
$$(HLIBRUSTUV_DEFAULT$(2)_H_$(4)) \
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
| $$(HLIB$(2)_H_$(4))/
build: Introduce rustsyntax crate
2012-03-22 17:27:35 -05:00
@$$(call E, cp: $$@)
Fix #3225: Incorporate feedback from Graydon. Namely, switched in many places to using GNU make provided functions for directory listing and text processing, rather than spawning a shell process to do that work. In the process of the revision, learned about Target-specific variables, which were very applicable to INSTALL_LIB (which, on a per-recipe basis, was always receiving the same actual arguments for its first two formal parameters in every invocation). http://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html (We might be able to make use of those in future refactorings.) ---- Also adds a cleanup pass to get-snapshot.py as well, since the same problem arises when we unpack libraries from the snapshot archive into a build directory with a prior snapshot's artifacts. (I put this step into the python script rather than the makefile because I wanted to delay the cleanup pass until after we have at least successfully downloaded the tarball. That way, if the download fails, you should not destroy the previous unarchived snapshot libraries and build products.) ---- Also reverted whitespace changes to minimize diff. I plan to put them back in in a dedicated commit elsewhere.
2013-07-08 11:35:47 -05:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBSYNTAX_GLOB_$(4)),$$(notdir $$@))
build: Introduce rustsyntax crate
2012-03-22 17:27:35 -05:00
$$(Q)cp $$< $$@
mk: cleanup - lib and executable suffix handling
2013-03-02 06:25:12 -06:00
$$(Q)cp -R $$(TLIB$(1)_T_$(4)_H_$(3))/$(LIBSYNTAX_GLOB_$(4)) \
$$(wildcard $$(TLIB$(1)_T_$(4)_H_$(3))/$(LIBSYNTAX_DSYM_GLOB_$(4))) \
build: Introduce rustsyntax crate
2012-03-22 17:27:35 -05:00
$$(HLIB$(2)_H_$(4))
Fix #3225: Incorporate feedback from Graydon. Namely, switched in many places to using GNU make provided functions for directory listing and text processing, rather than spawning a shell process to do that work. In the process of the revision, learned about Target-specific variables, which were very applicable to INSTALL_LIB (which, on a per-recipe basis, was always receiving the same actual arguments for its first two formal parameters in every invocation). http://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html (We might be able to make use of those in future refactorings.) ---- Also adds a cleanup pass to get-snapshot.py as well, since the same problem arises when we unpack libraries from the snapshot archive into a build directory with a prior snapshot's artifacts. (I put this step into the python script rather than the makefile because I wanted to delay the cleanup pass until after we have at least successfully downloaded the tarball. That way, if the download fails, you should not destroy the previous unarchived snapshot libraries and build products.) ---- Also reverted whitespace changes to minimize diff. I plan to put them back in in a dedicated commit elsewhere.
2013-07-08 11:35:47 -05:00
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBSYNTAX_GLOB_$(4)),$$(notdir $$@))
build: Introduce rustsyntax crate
2012-03-22 17:27:35 -05:00
mk: cleanup - lib and executable suffix handling
2013-03-02 06:25:12 -06:00
$$(HLIB$(2)_H_$(4))/$(CFG_RUNTIME_$(4)): \
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_$(4)_H_$(3))/$(CFG_RUNTIME_$(4)) \
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
| $$(HLIB$(2)_H_$(4))/
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
@$$(call E, cp: $$@)
$$(Q)cp $$< $$@
libstd: Rename libcore to libstd and libstd to libextra; update makefiles. This only changes the directory names; it does not change the "real" metadata names.
2013-05-17 12:45:09 -05:00
$$(HLIB$(2)_H_$(4))/$(CFG_STDLIB_$(4)): \
$$(TLIB$(1)_T_$(4)_H_$(3))/$(CFG_STDLIB_$(4)) \
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
$$(HLIB$(2)_H_$(4))/$(CFG_RUNTIME_$(4)) \
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
| $$(HLIB$(2)_H_$(4))/
Establish 'core' library separate from 'std'.
2011-12-05 18:46:37 -06:00
@$$(call E, cp: $$@)
Fix #3225: Incorporate feedback from Graydon. Namely, switched in many places to using GNU make provided functions for directory listing and text processing, rather than spawning a shell process to do that work. In the process of the revision, learned about Target-specific variables, which were very applicable to INSTALL_LIB (which, on a per-recipe basis, was always receiving the same actual arguments for its first two formal parameters in every invocation). http://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html (We might be able to make use of those in future refactorings.) ---- Also adds a cleanup pass to get-snapshot.py as well, since the same problem arises when we unpack libraries from the snapshot archive into a build directory with a prior snapshot's artifacts. (I put this step into the python script rather than the makefile because I wanted to delay the cleanup pass until after we have at least successfully downloaded the tarball. That way, if the download fails, you should not destroy the previous unarchived snapshot libraries and build products.) ---- Also reverted whitespace changes to minimize diff. I plan to put them back in in a dedicated commit elsewhere.
2013-07-08 11:35:47 -05:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(STDLIB_GLOB_$(4)),$$(notdir $$@))
Establish 'core' library separate from 'std'.
2011-12-05 18:46:37 -06:00
$$(Q)cp $$< $$@
Move rust's uv implementation to its own crate There are a few reasons that this is a desirable move to take: 1. Proof of concept that a third party event loop is possible 2. Clear separation of responsibility between rt::io and the uv-backend 3. Enforce in the future that the event loop is "pluggable" and replacable Here's a quick summary of the points of this pull request which make this possible: * Two new lang items were introduced: event_loop, and event_loop_factory. The idea of a "factory" is to define a function which can be called with no arguments and will return the new event loop as a trait object. This factory is emitted to the crate map when building an executable. The factory doesn't have to exist, and when it doesn't then an empty slot is in the crate map and a basic event loop with no I/O support is provided to the runtime. * When building an executable, then the rustuv crate will be linked by default (providing a default implementation of the event loop) via a similar method to injecting a dependency on libstd. This is currently the only location where the rustuv crate is ever linked. * There is a new #[no_uv] attribute (implied by #[no_std]) which denies implicitly linking to rustuv by default Closes #5019
2013-10-22 17:13:18 -05:00
# Subtle: We do not let the shell expand $$(STDLIB_DSYM_GLOB) directly rather
Revert "Try less complicated trick for solving the dSYM glob portability issue." This reverts commit 86dfca278dd5f9f589cecfe6de91ad8264c300d0.
2012-07-13 14:41:26 -05:00
# we use Make's $$(wildcard) facility. The reason is that, on mac, when using
libstd: Rename libcore to libstd and libstd to libextra; update makefiles. This only changes the directory names; it does not change the "real" metadata names.
2013-05-17 12:45:09 -05:00
# USE_SNAPSHOT_STDLIB, we copy the std.dylib file out of the snapshot.
Revert "Try less complicated trick for solving the dSYM glob portability issue." This reverts commit 86dfca278dd5f9f589cecfe6de91ad8264c300d0.
2012-07-13 14:41:26 -05:00
# In that case, there is no .dSYM file. Annoyingly, bash then refuses to expand
libstd: Rename libcore to libstd and libstd to libextra; update makefiles. This only changes the directory names; it does not change the "real" metadata names.
2013-05-17 12:45:09 -05:00
# glob, and cp reports an error because libstd-*.dylib.dsym does not exist.
Revert "Try less complicated trick for solving the dSYM glob portability issue." This reverts commit 86dfca278dd5f9f589cecfe6de91ad8264c300d0.
2012-07-13 14:41:26 -05:00
# Make instead expands the glob to nothing, which gives us the correct behavior.
# (Copy .dsym file if it exists, but do nothing otherwise)
libstd: Rename libcore to libstd and libstd to libextra; update makefiles. This only changes the directory names; it does not change the "real" metadata names.
2013-05-17 12:45:09 -05:00
$$(Q)cp -R $$(TLIB$(1)_T_$(4)_H_$(3))/$(STDLIB_GLOB_$(4)) \
$$(wildcard $$(TLIB$(1)_T_$(4)_H_$(3))/$(STDLIB_DSYM_GLOB_$(4))) \
rustc: build versioned library with hash in its name Also updated build to install versioned libraries and added a few missing actions for `make clean`.
2011-12-02 10:51:59 -06:00
$$(HLIB$(2)_H_$(4))
Fix #3225: Incorporate feedback from Graydon. Namely, switched in many places to using GNU make provided functions for directory listing and text processing, rather than spawning a shell process to do that work. In the process of the revision, learned about Target-specific variables, which were very applicable to INSTALL_LIB (which, on a per-recipe basis, was always receiving the same actual arguments for its first two formal parameters in every invocation). http://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html (We might be able to make use of those in future refactorings.) ---- Also adds a cleanup pass to get-snapshot.py as well, since the same problem arises when we unpack libraries from the snapshot archive into a build directory with a prior snapshot's artifacts. (I put this step into the python script rather than the makefile because I wanted to delay the cleanup pass until after we have at least successfully downloaded the tarball. That way, if the download fails, you should not destroy the previous unarchived snapshot libraries and build products.) ---- Also reverted whitespace changes to minimize diff. I plan to put them back in in a dedicated commit elsewhere.
2013-07-08 11:35:47 -05:00
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(STDLIB_GLOB_$(4)),$$(notdir $$@))
Establish 'core' library separate from 'std'.
2011-12-05 18:46:37 -06:00
libstd: Rename libcore to libstd and libstd to libextra; update makefiles. This only changes the directory names; it does not change the "real" metadata names.
2013-05-17 12:45:09 -05:00
$$(HLIB$(2)_H_$(4))/$(CFG_EXTRALIB_$(4)): \
$$(TLIB$(1)_T_$(4)_H_$(3))/$(CFG_EXTRALIB_$(4)) \
$$(HLIB$(2)_H_$(4))/$(CFG_STDLIB_$(4)) \
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
$$(HLIB$(2)_H_$(4))/$(CFG_RUNTIME_$(4)) \
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
| $$(HLIB$(2)_H_$(4))/
Establish 'core' library separate from 'std'.
2011-12-05 18:46:37 -06:00
@$$(call E, cp: $$@)
Fix #3225: Incorporate feedback from Graydon. Namely, switched in many places to using GNU make provided functions for directory listing and text processing, rather than spawning a shell process to do that work. In the process of the revision, learned about Target-specific variables, which were very applicable to INSTALL_LIB (which, on a per-recipe basis, was always receiving the same actual arguments for its first two formal parameters in every invocation). http://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html (We might be able to make use of those in future refactorings.) ---- Also adds a cleanup pass to get-snapshot.py as well, since the same problem arises when we unpack libraries from the snapshot archive into a build directory with a prior snapshot's artifacts. (I put this step into the python script rather than the makefile because I wanted to delay the cleanup pass until after we have at least successfully downloaded the tarball. That way, if the download fails, you should not destroy the previous unarchived snapshot libraries and build products.) ---- Also reverted whitespace changes to minimize diff. I plan to put them back in in a dedicated commit elsewhere.
2013-07-08 11:35:47 -05:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(EXTRALIB_GLOB_$(4)),$$(notdir $$@))
Establish 'core' library separate from 'std'.
2011-12-05 18:46:37 -06:00
$$(Q)cp $$< $$@
libstd: Rename libcore to libstd and libstd to libextra; update makefiles. This only changes the directory names; it does not change the "real" metadata names.
2013-05-17 12:45:09 -05:00
$$(Q)cp -R $$(TLIB$(1)_T_$(4)_H_$(3))/$(EXTRALIB_GLOB_$(4)) \
$$(wildcard $$(TLIB$(1)_T_$(4)_H_$(3))/$(EXTRALIB_DSYM_GLOB_$(4))) \
rustc: build versioned library with hash in its name Also updated build to install versioned libraries and added a few missing actions for `make clean`.
2011-12-02 10:51:59 -06:00
$$(HLIB$(2)_H_$(4))
Fix #3225: Incorporate feedback from Graydon. Namely, switched in many places to using GNU make provided functions for directory listing and text processing, rather than spawning a shell process to do that work. In the process of the revision, learned about Target-specific variables, which were very applicable to INSTALL_LIB (which, on a per-recipe basis, was always receiving the same actual arguments for its first two formal parameters in every invocation). http://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html (We might be able to make use of those in future refactorings.) ---- Also adds a cleanup pass to get-snapshot.py as well, since the same problem arises when we unpack libraries from the snapshot archive into a build directory with a prior snapshot's artifacts. (I put this step into the python script rather than the makefile because I wanted to delay the cleanup pass until after we have at least successfully downloaded the tarball. That way, if the download fails, you should not destroy the previous unarchived snapshot libraries and build products.) ---- Also reverted whitespace changes to minimize diff. I plan to put them back in in a dedicated commit elsewhere.
2013-07-08 11:35:47 -05:00
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(EXTRALIB_GLOB_$(4)),$$(notdir $$@))
Establish 'core' library separate from 'std'.
2011-12-05 18:46:37 -06:00
Move rust's uv implementation to its own crate There are a few reasons that this is a desirable move to take: 1. Proof of concept that a third party event loop is possible 2. Clear separation of responsibility between rt::io and the uv-backend 3. Enforce in the future that the event loop is "pluggable" and replacable Here's a quick summary of the points of this pull request which make this possible: * Two new lang items were introduced: event_loop, and event_loop_factory. The idea of a "factory" is to define a function which can be called with no arguments and will return the new event loop as a trait object. This factory is emitted to the crate map when building an executable. The factory doesn't have to exist, and when it doesn't then an empty slot is in the crate map and a basic event loop with no I/O support is provided to the runtime. * When building an executable, then the rustuv crate will be linked by default (providing a default implementation of the event loop) via a similar method to injecting a dependency on libstd. This is currently the only location where the rustuv crate is ever linked. * There is a new #[no_uv] attribute (implied by #[no_std]) which denies implicitly linking to rustuv by default Closes #5019
2013-10-22 17:13:18 -05:00
$$(HLIB$(2)_H_$(4))/$(CFG_LIBRUSTUV_$(4)): \
$$(TLIB$(1)_T_$(4)_H_$(3))/$(CFG_LIBRUSTUV_$(4)) \
$$(HLIB$(2)_H_$(4))/$(CFG_STDLIB_$(4)) \
$$(HLIB$(2)_H_$(4))/$(CFG_RUNTIME_$(4)) \
| $$(HLIB$(2)_H_$(4))/
@$$(call E, cp: $$@)
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBRUSTUV_GLOB_$(4)),$$(notdir $$@))
$$(Q)cp $$< $$@
$$(Q)cp -R $$(TLIB$(1)_T_$(4)_H_$(3))/$(LIBRUSTUV_GLOB_$(4)) \
$$(wildcard $$(TLIB$(1)_T_$(4)_H_$(3))/$(LIBRUSTUV_DSYM_GLOB_$(4))) \
$$(HLIB$(2)_H_$(4))
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBRUSTUV_GLOB_$(4)),$$(notdir $$@))
libstd: Rename libcore to libstd and libstd to libextra; update makefiles. This only changes the directory names; it does not change the "real" metadata names.
2013-05-17 12:45:09 -05:00
$$(HLIB$(2)_H_$(4))/libstd.rlib: \
$$(TLIB$(1)_T_$(4)_H_$(3))/libstd.rlib \
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
$$(HLIB$(2)_H_$(4))/$$(CFG_RUNTIME_$(4)) \
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
| $$(HLIB$(2)_H_$(4))/
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
@$$(call E, cp: $$@)
$$(Q)cp $$< $$@
libstd: Rename libcore to libstd and libstd to libextra; update makefiles. This only changes the directory names; it does not change the "real" metadata names.
2013-05-17 12:45:09 -05:00
$$(HLIB$(2)_H_$(4))/libextra.rlib: \
$$(TLIB$(1)_T_$(4)_H_$(3))/libextra.rlib \
$$(HLIB$(2)_H_$(4))/libstd.rlib \
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
$$(HLIB$(2)_H_$(4))/$$(CFG_RUNTIME_$(4)) \
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
| $$(HLIB$(2)_H_$(4))/
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
@$$(call E, cp: $$@)
$$(Q)cp $$< $$@
Update build machinery to build and install librustc everywhere (including snapshots).
2011-12-16 19:21:18 -06:00
$$(HLIB$(2)_H_$(4))/librustc.rlib: \
$$(TLIB$(1)_T_$(4)_H_$(3))/librustc.rlib \
$$(HLIB$(2)_H_$(4))/libstd.rlib \
libstd: Rename libcore to libstd and libstd to libextra; update makefiles. This only changes the directory names; it does not change the "real" metadata names.
2013-05-17 12:45:09 -05:00
$$(HLIB$(2)_H_$(4))/libextra.rlib \
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
$$(HLIB$(2)_H_$(4))/$$(CFG_RUNTIME_$(4)) \
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
| $$(HLIB$(2)_H_$(4))/
Update build machinery to build and install librustc everywhere (including snapshots).
2011-12-16 19:21:18 -06:00
@$$(call E, cp: $$@)
$$(Q)cp $$< $$@
mk: cleanup - lib and executable suffix handling
2013-03-02 06:25:12 -06:00
$$(HLIB$(2)_H_$(4))/$(CFG_RUSTLLVM_$(4)): \
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_$(4)_H_$(3))/$(CFG_RUSTLLVM_$(4)) \
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
| $$(HLIB$(2)_H_$(4))/
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
@$$(call E, cp: $$@)
$$(Q)cp $$< $$@
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
$$(HBIN$(2)_H_$(4))/:
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: target.mk host.mk fix for duplicated rules of mingw32 after #6235
2013-05-07 01:29:05 -05:00
ifneq ($(CFG_LIBDIR),bin)
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
$$(HLIB$(2)_H_$(4))/:
mkdir -p $$@
mk: target.mk host.mk fix for duplicated rules of mingw32 after #6235
2013-05-07 01:29:05 -05:00
endif
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
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
endef
support for GNU configure syntax
2013-10-21 04:18:21 -05:00
$(foreach t,$(CFG_HOST), \
basic builds function
2011-11-21 15:11:40 -06:00
$(eval $(call CP_HOST_STAGE_N,0,1,$(t),$(t))) \
$(eval $(call CP_HOST_STAGE_N,1,2,$(t),$(t))) \
$(eval $(call CP_HOST_STAGE_N,2,3,$(t),$(t))))
Reference in New Issue Copy Permalink