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

165 lines
6.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
support for GNU configure syntax
2013-10-21 04:18:21 -05:00
export CFG_COMPILER
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+)
WFLAGS_ST0 = -W warnings
Deny common lints by default for lib{std,extra}
2013-06-25 19:02:03 -05:00
WFLAGS_ST1 = -D warnings
WFLAGS_ST2 = -D warnings
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
# TARGET_STAGE_N template: This defines how target artifacts are built
basic builds function
2011-11-21 15:11:40 -06:00
# for all stage/target architecture combinations. The arguments:
# $(1) is the stage
# $(2) is the target triple
# $(3) is the host triple
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
small cleanup of previous commit with mucho comments.
2013-08-31 17:53:56 -05:00
# Every recipe in TARGET_STAGE_N outputs to $$(TLIB$(1)_T_$(2)_H_$(3),
# 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
# inadvertantly included in the clean out.
make use of snapshot runtime predicated on variable USE_SNAPSHOT_RUNTIME
2012-01-09 16:08:08 -06:00
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
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
define TARGET_STAGE_N
basic builds function
2011-11-21 15:11:40 -06:00
$$(TLIB$(1)_T_$(2)_H_$(3))/libmorestack.a: \
Move the `rt` build directory under $target Closes #2302
2013-09-04 02:45:01 -05:00
$(2)/rt/stage$(1)/arch/$$(HOST_$(2))/libmorestack.a \
hypothetical fix for #8865.
2013-08-31 14:44:50 -05:00
| $$(TLIB$(1)_T_$(2)_H_$(3))/ \
small cleanup of previous commit with mucho comments.
2013-08-31 17:53:56 -05:00
$(SNAPSHOT_RUSTC_POST_CLEANUP)
rt: Build __morestack as a static library and copy it to the right places
2011-11-28 19:23:13 -06:00
@$$(call E, cp: $$@)
$$(Q)cp $$< $$@
mk: rewrite make files
2013-02-26 23:53:35 -06:00
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_RUNTIME_$(2)): \
Move the `rt` build directory under $target Closes #2302
2013-09-04 02:45:01 -05:00
$(2)/rt/stage$(1)/$(CFG_RUNTIME_$(2)) \
hypothetical fix for #8865.
2013-08-31 14:44:50 -05:00
| $$(TLIB$(1)_T_$(2)_H_$(3))/ \
small cleanup of previous commit with mucho comments.
2013-08-31 17:53:56 -05:00
$(SNAPSHOT_RUSTC_POST_CLEANUP)
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
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_STDLIB_$(2)): \
$$(STDLIB_CRATE) $$(STDLIB_INPUTS) \
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
$$(TSREQ$(1)_T_$(2)_H_$(3)) \
| $$(TLIB$(1)_T_$(2)_H_$(3))/
build: Introduce rustsyntax crate
2012-03-22 17:27:35 -05:00
@$$(call E, compile_and_link: $$@)
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_$(2)),$$(notdir $$@))
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(STDLIB_RGLOB_$(2)),$$(notdir $$@))
Warn when using -o option on libraries. Closes #6554.
2013-07-30 17:40:19 -05:00
$$(STAGE$(1)_T_$(2)_H_$(3)) $$(WFLAGS_ST$(1)) --out-dir $$(@D) $$< && touch $$@
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_$(2)),$$(notdir $$@))
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(STDLIB_RGLOB_$(2)),$$(notdir $$@))
build: Introduce rustsyntax crate
2012-03-22 17:27:35 -05: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
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_EXTRALIB_$(2)): \
$$(EXTRALIB_CRATE) $$(EXTRALIB_INPUTS) \
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_STDLIB_$(2)) \
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
$$(TSREQ$(1)_T_$(2)_H_$(3)) \
| $$(TLIB$(1)_T_$(2)_H_$(3))/
Rename src/rustc to src/librustc. Use the driver crate
2012-11-06 21:44:58 -06:00
@$$(call E, compile_and_link: $$@)
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_$(2)),$$(notdir $$@))
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(EXTRALIB_RGLOB_$(2)),$$(notdir $$@))
Warn when using -o option on libraries. Closes #6554.
2013-07-30 17:40:19 -05:00
$$(STAGE$(1)_T_$(2)_H_$(3)) $$(WFLAGS_ST$(1)) --out-dir $$(@D) $$< && touch $$@
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_$(2)),$$(notdir $$@))
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(EXTRALIB_RGLOB_$(2)),$$(notdir $$@))
Rename src/rustc to src/librustc. Use the driver crate
2012-11-06 21:44:58 -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
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_LIBRUSTUV_$(2)): \
$$(LIBRUSTUV_CRATE) $$(LIBRUSTUV_INPUTS) \
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_STDLIB_$(2)) \
$$(TSREQ$(1)_T_$(2)_H_$(3)) \
Statically link libuv to librustuv Similarly to the previous commit, libuv is only used by this library, so there's no need for it to be linked into librustrt and available to all crates by default.
2013-10-31 01:57:27 -05:00
$$(LIBUV_LIB_$(2)) \
$$(UV_SUPPORT_LIB_$(2)) \
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
| $$(TLIB$(1)_T_$(2)_H_$(3))/
@$$(call E, compile_and_link: $$@)
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBRUSTUV_GLOB_$(2)),$$(notdir $$@))
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBRUSTUV_RGLOB_$(2)),$$(notdir $$@))
Statically link libuv to librustuv Similarly to the previous commit, libuv is only used by this library, so there's no need for it to be linked into librustrt and available to all crates by default.
2013-10-31 01:57:27 -05:00
$$(STAGE$(1)_T_$(2)_H_$(3)) $$(WFLAGS_ST$(1)) \
-L $$(UV_SUPPORT_DIR_$(2)) \
-L $$(dir $$(LIBUV_LIB_$(2))) \
--out-dir $$(@D) $$< && touch $$@
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
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBRUSTUV_GLOB_$(2)),$$(notdir $$@))
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBRUSTUV_RGLOB_$(2)),$$(notdir $$@))
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
mk: rewrite make files
2013-02-26 23:53:35 -06:00
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_LIBSYNTAX_$(3)): \
Rename librustsyntax to libsyntax Per issue #2418.
2012-05-29 23:35:12 -05:00
$$(LIBSYNTAX_CRATE) $$(LIBSYNTAX_INPUTS) \
Separate driver rustc and librustc rustc is now a minimal wrapper of librustc.
2011-12-20 04:17:13 -06:00
$$(TSREQ$(1)_T_$(2)_H_$(3)) \
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
$$(TSTDLIB_DEFAULT$(1)_T_$(2)_H_$(3)) \
$$(TEXTRALIB_DEFAULT$(1)_T_$(2)_H_$(3)) \
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
$$(TLIBRUSTUV_DEFAULT$(1)_T_$(2)_H_$(3)) \
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))/
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, compile_and_link: $$@)
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_$(2)),$$(notdir $$@))
Deny warnings in stage1+ libsyntax/librustc/librustdoc/librusti/librust
2013-08-17 10:37:12 -05:00
$$(STAGE$(1)_T_$(2)_H_$(3)) $$(WFLAGS_ST$(1)) $(BORROWCK) --out-dir $$(@D) $$< && touch $$@
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_$(2)),$$(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: Split target triples into bulid triple + host triples + target triples For cross compiling to targets that don't want to build a compiler
2013-02-21 18:15:01 -06:00
# Only build the compiler for host triples
support for GNU configure syntax
2013-10-21 04:18:21 -05:00
ifneq ($$(findstring $(2),$$(CFG_HOST)),)
mk: Split target triples into bulid triple + host triples + target triples For cross compiling to targets that don't want to build a compiler
2013-02-21 18:15:01 -06:00
mk: rewrite make files
2013-02-26 23:53:35 -06:00
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_RUSTLLVM_$(3)): \
Build rustllvm into $target/rustllvm
2013-09-04 01:48:45 -05:00
$(2)/rustllvm/$(CFG_RUSTLLVM_$(3)) \
hypothetical fix for #8865.
2013-08-31 14:44:50 -05:00
| $$(TLIB$(1)_T_$(2)_H_$(3))/ \
small cleanup of previous commit with mucho comments.
2013-08-31 17:53:56 -05:00
$(SNAPSHOT_RUSTC_POST_CLEANUP)
fix how we walk functions to match new closure fmt
2012-01-06 14:06:35 -06:00
@$$(call E, cp: $$@)
$$(Q)cp $$< $$@
support for GNU configure syntax
2013-10-21 04:18:21 -05:00
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_LIBRUSTC_$(3)): CFG_COMPILER = $(2)
mk: rewrite make files
2013-02-26 23:53:35 -06:00
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_LIBRUSTC_$(3)): \
mk: Split target triples into bulid triple + host triples + target triples For cross compiling to targets that don't want to build a compiler
2013-02-21 18:15:01 -06:00
$$(COMPILER_CRATE) $$(COMPILER_INPUTS) \
Add dependence arc from running rustc to its libraries. This commit fixes some oversights in the Makefile where rustc could be invoked without some of its dependencies yet in place. (I encountered the problem in practice; its not just theoretical.) As written in Makefile.in, $(STAGE$(1)_T_$(2)_H_$(3)) is the way one writes an invocation of rustc where $(1) is the stage number $(2) is the target triple $(3) is the host triple. (Other uses of the macro may plug in actual values or different parameters in for those three formal parameters.) When you have invocations of $(STAGE...), you need to make sure that its dependences are satisfied; otherwise, if someone is using `make -jN` for certain (large-ish) `N`, one can encounter situations where GNU make attempts to invoke `rustc` before it has actually copied some of its libraries into place, such as libmorestack.a, which causes a link failure when the rustc invocation attempts to link in those libraries. In this case, the main prerequisite to add is TSREQ$(1)_T_$(2)_H_$(3), which is described in Makefile.in as "Prerequisites for using the stageN compiler to build target artifacts" ---- In addition to adding the extra dependences on TSREQ..., I also replaced occurrences of the pattern: TSREQ$(1)_T_$(2)_H_$(3) $$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_STDLIB_$(2)) $$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_EXTRALIB_$(2)) with: SREQ$(1)_T_$(2)_H_$(3) which is equivalent to the above, as defined in Makefile.in ---- Finally, for the cases where TSREQ was missing in tests.mk, I went ahead and put in a dependence on SREQ rather than just TSREQ, since it was not clear to me how one could expect to compile those cases without stdlib and extralib. (It could well be that I should have gone ahead and done the same in other cases where I saw TSREQ was missing, and put SREQ in those cases as well. But this seemed like a good measure for now, without needing to tax my understanding of the overall makefile infrastructure much further.)
2013-07-16 01:05:18 -05:00
$$(TSREQ$(1)_T_$(2)_H_$(3)) \
mk: rewrite make files
2013-02-26 23:53:35 -06:00
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_LIBSYNTAX_$(3)) \
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))/$(CFG_RUSTLLVM_$(3)) \
| $$(TLIB$(1)_T_$(2)_H_$(3))/
make it possible to use snapshot core lib
2012-03-16 09:14:33 -05:00
@$$(call E, compile_and_link: $$@)
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_$(2)),$$(notdir $$@))
Deny warnings in stage1+ libsyntax/librustc/librustdoc/librusti/librust
2013-08-17 10:37:12 -05:00
$$(STAGE$(1)_T_$(2)_H_$(3)) $$(WFLAGS_ST$(1)) --out-dir $$(@D) $$< && touch $$@
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_$(2)),$$(notdir $$@))
make it possible to use snapshot core lib
2012-03-16 09:14:33 -05:00
Statically link libuv to librustuv Similarly to the previous commit, libuv is only used by this library, so there's no need for it to be linked into librustrt and available to all crates by default.
2013-10-31 01:57:27 -05:00
# NOTE: after the next snapshot remove these '-L' flags
mk: cleanup - lib and executable suffix handling
2013-03-02 06:25:12 -06:00
$$(TBIN$(1)_T_$(2)_H_$(3))/rustc$$(X_$(3)): \
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
$$(DRIVER_CRATE) \
Add dependence arc from running rustc to its libraries. This commit fixes some oversights in the Makefile where rustc could be invoked without some of its dependencies yet in place. (I encountered the problem in practice; its not just theoretical.) As written in Makefile.in, $(STAGE$(1)_T_$(2)_H_$(3)) is the way one writes an invocation of rustc where $(1) is the stage number $(2) is the target triple $(3) is the host triple. (Other uses of the macro may plug in actual values or different parameters in for those three formal parameters.) When you have invocations of $(STAGE...), you need to make sure that its dependences are satisfied; otherwise, if someone is using `make -jN` for certain (large-ish) `N`, one can encounter situations where GNU make attempts to invoke `rustc` before it has actually copied some of its libraries into place, such as libmorestack.a, which causes a link failure when the rustc invocation attempts to link in those libraries. In this case, the main prerequisite to add is TSREQ$(1)_T_$(2)_H_$(3), which is described in Makefile.in as "Prerequisites for using the stageN compiler to build target artifacts" ---- In addition to adding the extra dependences on TSREQ..., I also replaced occurrences of the pattern: TSREQ$(1)_T_$(2)_H_$(3) $$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_STDLIB_$(2)) $$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_EXTRALIB_$(2)) with: SREQ$(1)_T_$(2)_H_$(3) which is equivalent to the above, as defined in Makefile.in ---- Finally, for the cases where TSREQ was missing in tests.mk, I went ahead and put in a dependence on SREQ rather than just TSREQ, since it was not clear to me how one could expect to compile those cases without stdlib and extralib. (It could well be that I should have gone ahead and done the same in other cases where I saw TSREQ was missing, and put SREQ in those cases as well. But this seemed like a good measure for now, without needing to tax my understanding of the overall makefile infrastructure much further.)
2013-07-16 01:05:18 -05:00
$$(TSREQ$(1)_T_$(2)_H_$(3)) \
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))/$(CFG_LIBRUSTC_$(3)) \
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))/
build: Add USE_SNAPSHOT_STDLIB. Set to 1
2012-05-22 13:40:46 -05:00
@$$(call E, compile_and_link: $$@)
Statically link libuv to librustuv Similarly to the previous commit, libuv is only used by this library, so there's no need for it to be linked into librustrt and available to all crates by default.
2013-10-31 01:57:27 -05:00
$$(STAGE$(1)_T_$(2)_H_$(3)) --cfg rustc -o $$@ $$< \
-L $$(UV_SUPPORT_DIR_$(2)) \
-L $$(dir $$(LIBUV_LIB_$(2)))
mk: Split target triples into bulid triple + host triples + target triples For cross compiling to targets that don't want to build a compiler
2013-02-21 18:15:01 -06:00
ifdef CFG_ENABLE_PAX_FLAGS
@$$(call E, apply PaX flags: $$@)
@"$(CFG_PAXCTL)" -cm "$$@"
endif
endif
build: Add USE_SNAPSHOT_STDLIB. Set to 1
2012-05-22 13:40:46 -05: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 $$@
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)
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 $$@
mk: target.mk host.mk fix for duplicated rules of mingw32 after #6235
2013-05-07 01:29:05 -05:00
endif
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
build: Add USE_SNAPSHOT_STDLIB. Set to 1
2012-05-22 13:40:46 -05:00
endef
makefiles now seem to be working, rustc is not
2011-11-22 15:04:52 -06:00
# In principle, each host can build each target:
support for GNU configure syntax
2013-10-21 04:18:21 -05:00
$(foreach source,$(CFG_HOST), \
$(foreach target,$(CFG_TARGET), \
fix how we walk functions to match new closure fmt
2012-01-06 14:06:35 -06:00
$(eval $(call TARGET_STAGE_N,0,$(target),$(source))) \
$(eval $(call TARGET_STAGE_N,1,$(target),$(source))) \
$(eval $(call TARGET_STAGE_N,2,$(target),$(source))) \
$(eval $(call TARGET_STAGE_N,3,$(target),$(source)))))
Reference in New Issue Copy Permalink