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

144 lines
4.8 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)) \
Establish 'core' library separate from 'std'.
2011-12-06 01:46:37 +01:00
$$(HCORELIB_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
$$(HSTDLIB_DEFAULT$(2)_H_$(4)) \
| $$(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)) \
$$(HCORELIB_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
$$(HSTDLIB_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: $$@)
$$(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)) \
$(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))
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)) \
$$(HCORELIB_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
$$(HSTDLIB_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: $$@)
$$(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))
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 $$< $$@
mk: cleanup - lib and executable suffix handling
2013-03-02 13:25:12 +01:00
$$(HLIB$(2)_H_$(4))/$(CFG_CORELIB_$(4)): \
$$(TLIB$(1)_T_$(4)_H_$(3))/$(CFG_CORELIB_$(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: $$@)
$$(Q)cp $$< $$@
Revert "Try less complicated trick for solving the dSYM glob portability issue." This reverts commit 86dfca278dd5f9f589cecfe6de91ad8264c300d0.
2012-07-13 21:41:26 +02:00
# Subtle: We do not let the shell expand $(CORELIB_DSYM_GLOB) directly rather
# we use Make's $$(wildcard) facility. The reason is that, on mac, when using
# USE_SNAPSHOT_CORELIB, we copy the core.dylib file out of the snapshot.
# In that case, there is no .dSYM file. Annoyingly, bash then refuses to expand
# glob, and cp reports an error because libcore-*.dylib.dsym does not exist.
# Make instead expands the glob to nothing, which gives us the correct behavior.
# (Copy .dsym file if it exists, but do nothing otherwise)
mk: cleanup - lib and executable suffix handling
2013-03-02 13:25:12 +01:00
$$(Q)cp -R $$(TLIB$(1)_T_$(4)_H_$(3))/$(CORELIB_GLOB_$(4)) \
$$(wildcard $$(TLIB$(1)_T_$(4)_H_$(3))/$(CORELIB_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))
Establish 'core' library separate from 'std'.
2011-12-06 01:46:37 +01:00
mk: cleanup - lib and executable suffix handling
2013-03-02 13:25:12 +01:00
$$(HLIB$(2)_H_$(4))/$(CFG_STDLIB_$(4)): \
$$(TLIB$(1)_T_$(4)_H_$(3))/$(CFG_STDLIB_$(4)) \
$$(HLIB$(2)_H_$(4))/$(CFG_CORELIB_$(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: $$@)
$$(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))/$(STDLIB_GLOB_$(4)) \
$$(wildcard $$(TLIB$(1)_T_$(4)_H_$(3))/$(STDLIB_DSYM_GLOB_$(4))) \
rustc: build versioned library with hash in its name Also updated build to install versioned libraries and added a few missing actions for `make clean`.
2011-12-02 17:51:59 +01:00
$$(HLIB$(2)_H_$(4))
Establish 'core' library separate from 'std'.
2011-12-06 01:46:37 +01:00
$$(HLIB$(2)_H_$(4))/libcore.rlib: \
$$(TLIB$(1)_T_$(4)_H_$(3))/libcore.rlib \
Make build products depend on their target directories. This is an attempt to address Issue #3326 by adding [*order-only*][1] prerequsites of each build product on the directory where it is to go. It is important that the prerequisites be order-only, since the timestamp on a parent directory is not relevant to whether a product is out of date; the parent directory merely needs to exist. (This use case of generating target directories was provided as an [example][2] of how order-only prequisites are used.) [1]: http://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html [2]: http://www.kolpackov.net/pipermail/notes/2004-January/000001.html
2013-05-03 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))/
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 $$< $$@
basic builds function
2011-11-21 22:11:40 +01:00
$$(HLIB$(2)_H_$(4))/libstd.rlib: \
$$(TLIB$(1)_T_$(4)_H_$(3))/libstd.rlib \
Establish 'core' library separate from 'std'.
2011-12-06 01:46:37 +01:00
$$(HLIB$(2)_H_$(4))/libcore.rlib \
Make build products depend on their target directories. This is an attempt to address Issue #3326 by adding [*order-only*][1] prerequsites of each build product on the directory where it is to go. It is important that the prerequisites be order-only, since the timestamp on a parent directory is not relevant to whether a product is out of date; the parent directory merely needs to exist. (This use case of generating target directories was provided as an [example][2] of how order-only prequisites are used.) [1]: http://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html [2]: http://www.kolpackov.net/pipermail/notes/2004-January/000001.html
2013-05-03 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))/
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 $$< $$@
Update build machinery to build and install librustc everywhere (including snapshots).
2011-12-17 02:21:18 +01:00
$$(HLIB$(2)_H_$(4))/librustc.rlib: \
$$(TLIB$(1)_T_$(4)_H_$(3))/librustc.rlib \
$$(HLIB$(2)_H_$(4))/libcore.rlib \
$$(HLIB$(2)_H_$(4))/libstd.rlib \
Make build products depend on their target directories. This is an attempt to address Issue #3326 by adding [*order-only*][1] prerequsites of each build product on the directory where it is to go. It is important that the prerequisites be order-only, since the timestamp on a parent directory is not relevant to whether a product is out of date; the parent directory merely needs to exist. (This use case of generating target directories was provided as an [example][2] of how order-only prequisites are used.) [1]: http://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html [2]: http://www.kolpackov.net/pipermail/notes/2004-January/000001.html
2013-05-03 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))/
Update build machinery to build and install librustc everywhere (including snapshots).
2011-12-17 02:21:18 +01: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_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
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-22 01:15:01 +01:00
$(foreach t,$(CFG_HOST_TRIPLES), \
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