OpenE2K/rust
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
e2d192c9f4
rust/mk/host.mk

153 lines
6.3 KiB
Makefile
Raw Normal View History

Reliciense makefiles and testsuite. Yup.
2012-12-11 02:32:48 +01: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 22:11:40 +01: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-02 05:12:08 +02: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 22:11:40 +01: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-02 05:12:08 +02:00
# Host libraries and executables (stage$(2)/bin/rustc and its runtime needs)
mk: cleanup - lib and executable suffix handling
2013-03-02 13:25:12 +01: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 18:53:47 +02: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 19:45:09 +02: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-23 00:13:18 +02: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 18:53:47 +02: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-02 05:12:08 +02:00
@$$(call E, cp: $$@)
$$(Q)cp $$< $$@
mk: cleanup - lib and executable suffix handling
2013-03-02 13:25:12 +01: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 18:53:47 +02: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 19:45:09 +02: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-23 00:13:18 +02: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 12:46:11 +02: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 18:53:47 +02: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-02 05:12:08 +02: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 18:35:47 +02: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-02 05:12:08 +02:00
$$(Q)cp $$< $$@
mk: cleanup - lib and executable suffix handling
2013-03-02 13:25:12 +01:00
$$(Q)cp -R $$(TLIB$(1)_T_$(4)_H_$(3))/$(LIBRUSTC_GLOB_$(4)) \
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 23:03:29 +01:00
$$(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 17:51:59 +01: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 18:35:47 +02: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-02 05:12:08 +02:00
mk: cleanup - lib and executable suffix handling
2013-03-02 13:25:12 +01: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 18:53:47 +02: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 19:45:09 +02: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-23 00:13:18 +02: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 12:46:11 +02:00
| $$(HLIB$(2)_H_$(4))/
build: Introduce rustsyntax crate
2012-03-22 23:27:35 +01: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 18:35:47 +02:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBSYNTAX_GLOB_$(4)),$$(notdir $$@))
build: Introduce rustsyntax crate
2012-03-22 23:27:35 +01:00
$$(Q)cp $$< $$@
mk: cleanup - lib and executable suffix handling
2013-03-02 13:25:12 +01: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 23:27:35 +01: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 18:35:47 +02:00
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBSYNTAX_GLOB_$(4)),$$(notdir $$@))
build: Introduce rustsyntax crate
2012-03-22 23:27:35 +01:00
mk: cleanup - lib and executable suffix handling
2013-03-02 13:25:12 +01: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 18:53:47 +02: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 12:46:11 +02: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-02 05:12:08 +02: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 19:45:09 +02: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 18:53:47 +02: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 12:46:11 +02:00
| $$(HLIB$(2)_H_$(4))/
Establish 'core' library separate from 'std'.
2011-12-06 01:46:37 +01: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 18:35:47 +02:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(STDLIB_GLOB_$(4)),$$(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 23:03:29 +01:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(STDLIB_RGLOB_$(4)),$$(notdir $$@))
Establish 'core' library separate from 'std'.
2011-12-06 01:46:37 +01: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-23 00:13:18 +02: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 21:41:26 +02: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 19:45:09 +02: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 21:41:26 +02: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 19:45:09 +02: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 21:41:26 +02: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 19:45:09 +02:00
$$(Q)cp -R $$(TLIB$(1)_T_$(4)_H_$(3))/$(STDLIB_GLOB_$(4)) \
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 23:03:29 +01:00
$$(wildcard $$(TLIB$(1)_T_$(4)_H_$(3))/$(STDLIB_RGLOB_$(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 19:45:09 +02:00
$$(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 17:51:59 +01: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 18:35:47 +02:00
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(STDLIB_GLOB_$(4)),$$(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 23:03:29 +01:00
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(STDLIB_RGLOB_$(4)),$$(notdir $$@))
Establish 'core' library separate from 'std'.
2011-12-06 01:46:37 +01: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 19:45:09 +02: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 18:53:47 +02: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 12:46:11 +02:00
| $$(HLIB$(2)_H_$(4))/
Establish 'core' library separate from 'std'.
2011-12-06 01:46:37 +01: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 18:35:47 +02:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(EXTRALIB_GLOB_$(4)),$$(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 23:03:29 +01:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(EXTRALIB_RGLOB_$(4)),$$(notdir $$@))
Establish 'core' library separate from 'std'.
2011-12-06 01:46:37 +01: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 19:45:09 +02:00
$$(Q)cp -R $$(TLIB$(1)_T_$(4)_H_$(3))/$(EXTRALIB_GLOB_$(4)) \
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 23:03:29 +01:00
$$(wildcard $$(TLIB$(1)_T_$(4)_H_$(3))/$(EXTRALIB_RGLOB_$(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 19:45:09 +02:00
$$(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 17:51:59 +01: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 18:35:47 +02:00
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(EXTRALIB_GLOB_$(4)),$$(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 23:03:29 +01:00
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(EXTRALIB_RGLOB_$(4)),$$(notdir $$@))
Establish 'core' library separate from 'std'.
2011-12-06 01:46:37 +01: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-23 00:13:18 +02: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 $$@))
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 23:03:29 +01:00
$$(call REMOVE_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBRUSTUV_RGLOB_$(4)),$$(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-23 00:13:18 +02:00
$$(Q)cp $$< $$@
$$(Q)cp -R $$(TLIB$(1)_T_$(4)_H_$(3))/$(LIBRUSTUV_GLOB_$(4)) \
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 23:03:29 +01:00
$$(wildcard $$(TLIB$(1)_T_$(4)_H_$(3))/$(LIBRUSTUV_RGLOB_$(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-23 00:13:18 +02:00
$$(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 $$@))
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 23:03:29 +01:00
$$(call LIST_ALL_OLD_GLOB_MATCHES_EXCEPT,$$(dir $$@),$(LIBRUSTUV_RGLOB_$(4)),$$(notdir $$@))
Update build machinery to build and install librustc everywhere (including snapshots).
2011-12-17 02:21:18 +01:00
mk: cleanup - lib and executable suffix handling
2013-03-02 13:25:12 +01: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 18:53:47 +02: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 12:46:11 +02: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-02 05:12:08 +02: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 18:53:47 +02:00
$$(HBIN$(2)_H_$(4))/:
Fix syntax: had to use escaped $$ to have an effect after first expansion.
2013-05-04 10:57:56 +02: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 18:53:47 +02:00
mk: target.mk host.mk fix for duplicated rules of mingw32 after #6235
2013-05-07 08:29:05 +02: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 12:46:11 +02:00
$$(HLIB$(2)_H_$(4))/:
mkdir -p $$@
mk: target.mk host.mk fix for duplicated rules of mingw32 after #6235
2013-05-07 08:29:05 +02: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 12:46:11 +02: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-02 05:12:08 +02:00
endef
support for GNU configure syntax
2013-10-21 11:18:21 +02:00
$(foreach t,$(CFG_HOST), \
basic builds function
2011-11-21 22:11:40 +01: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