2014-12-12 23:39:27 +00:00
|
|
|
# Copyright 2012-2015 The Rust Project Developers. See the COPYRIGHT
|
2012-12-11 01:32:48 +00:00
|
|
|
# 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.
|
|
|
|
|
|
2011-05-04 01:09:18 +00:00
|
|
|
|
2011-11-01 23:50:47 +00:00
|
|
|
# Create variables HOST_<triple> containing the host part
|
|
|
|
|
# of each target triple. For example, the triple i686-darwin-macos
|
2013-05-03 23:25:04 +00:00
|
|
|
# would create a variable HOST_i686-darwin-macos with the value
|
2011-11-01 23:50:47 +00:00
|
|
|
# i386.
|
|
|
|
|
define DEF_HOST_VAR
|
2015-11-16 23:01:58 +00:00
|
|
|
HOST_$(1) = $(patsubst i%86,i386,$(word 1,$(subst -, ,$(1))))
|
2011-11-01 23:50:47 +00:00
|
|
|
endef
|
2013-10-21 09:18:21 +00:00
|
|
|
$(foreach t,$(CFG_TARGET),$(eval $(call DEF_HOST_VAR,$(t))))
|
|
|
|
|
$(foreach t,$(CFG_TARGET),$(info cfg: host for $(t) is $(HOST_$(t))))
|
2011-11-01 23:50:47 +00:00
|
|
|
|
2013-02-22 03:10:16 +00:00
|
|
|
# Ditto for OSTYPE
|
|
|
|
|
define DEF_OSTYPE_VAR
|
|
|
|
|
OSTYPE_$(1) = $(subst $(firstword $(subst -, ,$(1)))-,,$(1))
|
|
|
|
|
endef
|
2013-10-21 09:18:21 +00:00
|
|
|
$(foreach t,$(CFG_TARGET),$(eval $(call DEF_OSTYPE_VAR,$(t))))
|
|
|
|
|
$(foreach t,$(CFG_TARGET),$(info cfg: os for $(t) is $(OSTYPE_$(t))))
|
2013-02-22 03:10:16 +00:00
|
|
|
|
2011-05-01 20:18:52 +00:00
|
|
|
# On Darwin, we need to run dsymutil so the debugging information ends
|
|
|
|
|
# up in the right place. On other platforms, it automatically gets
|
|
|
|
|
# embedded into the executable, so use a no-op command.
|
|
|
|
|
CFG_DSYMUTIL := true
|
|
|
|
|
|
2013-03-07 06:36:20 +00:00
|
|
|
# Hack: not sure how to test if a file exists in make other than this
|
2014-07-23 04:45:08 +00:00
|
|
|
OS_SUPP = $(patsubst %,--suppressions=%, \
|
2013-03-07 06:36:20 +00:00
|
|
|
$(wildcard $(CFG_SRC_DIR)src/etc/$(CFG_OSTYPE).supp*))
|
|
|
|
|
|
|
|
|
|
ifdef CFG_DISABLE_OPTIMIZE_CXX
|
|
|
|
|
$(info cfg: disabling C++ optimization (CFG_DISABLE_OPTIMIZE_CXX))
|
|
|
|
|
CFG_GCCISH_CFLAGS += -O0
|
|
|
|
|
else
|
|
|
|
|
CFG_GCCISH_CFLAGS += -O2
|
|
|
|
|
endif
|
|
|
|
|
|
2013-09-16 22:25:01 +00:00
|
|
|
# The soname thing is for supporting a statically linked jemalloc.
|
|
|
|
|
# see https://blog.mozilla.org/jseward/2012/06/05/valgrind-now-supports-jemalloc-builds-directly/
|
2013-03-07 06:36:20 +00:00
|
|
|
ifdef CFG_VALGRIND
|
|
|
|
|
CFG_VALGRIND += --error-exitcode=100 \
|
2015-04-17 14:45:16 +00:00
|
|
|
--fair-sched=try \
|
2013-03-07 06:36:20 +00:00
|
|
|
--quiet \
|
2015-04-17 14:45:16 +00:00
|
|
|
--soname-synonyms=somalloc=NONE \
|
2013-03-07 06:36:20 +00:00
|
|
|
--suppressions=$(CFG_SRC_DIR)src/etc/x86.supp \
|
|
|
|
|
$(OS_SUPP)
|
|
|
|
|
ifdef CFG_ENABLE_HELGRIND
|
|
|
|
|
CFG_VALGRIND += --tool=helgrind
|
|
|
|
|
else
|
|
|
|
|
CFG_VALGRIND += --tool=memcheck \
|
|
|
|
|
--leak-check=full
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
2014-10-08 23:11:37 +00:00
|
|
|
# If we actually want to run Valgrind on a given platform, set this variable
|
|
|
|
|
define DEF_GOOD_VALGRIND
|
|
|
|
|
ifeq ($(OSTYPE_$(1)),unknown-linux-gnu)
|
|
|
|
|
GOOD_VALGRIND_$(1) = 1
|
|
|
|
|
endif
|
2015-12-13 15:09:52 +00:00
|
|
|
ifneq (,$(filter $(OSTYPE_$(1)),apple-darwin freebsd))
|
|
|
|
|
ifeq ($(HOST_$(1)),x86_64)
|
2014-10-08 23:11:37 +00:00
|
|
|
GOOD_VALGRIND_$(1) = 1
|
|
|
|
|
endif
|
|
|
|
|
endif
|
2015-12-13 15:09:52 +00:00
|
|
|
ifdef GOOD_VALGRIND_$(t)
|
|
|
|
|
$$(info cfg: have good valgrind for $(t))
|
|
|
|
|
else
|
|
|
|
|
$$(info cfg: no good valgrind for $(t))
|
|
|
|
|
endif
|
2014-10-08 23:11:37 +00:00
|
|
|
endef
|
|
|
|
|
$(foreach t,$(CFG_TARGET),$(eval $(call DEF_GOOD_VALGRIND,$(t))))
|
|
|
|
|
|
2013-03-07 06:36:20 +00:00
|
|
|
AR := ar
|
|
|
|
|
|
Make configure respect (and save) values for `CC`, `CXX`, `CFLAGS`, etc.
I mostly tried to remain backwards compatible with old invocations of
the `configure` script; if you do not want to use `CC` et al., you
should not have to; you can keep using `--enable-clang` and/or
`--enable-ccache`.
The overall intention is to capture the following precedences for
guessing the C compiler:
1. Value of `CC` at make invocation time.
2. Value of `CC` at configure invocation time.
3. Compiler inferred at configure invocation time (`gcc` or `clang`).
The strategy is to check (at `configure` time) if each of the
environment variables is set, and if so, save its value in a
corresponding `CFG_` variable (e.g. `CFG_CC`).
Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we
use the `CFG_CC` setting as `CC`.
Also, I fold the potential user-provided `CFLAGS` and `CXXFLAGS`
values into all of the per-platform `CFLAGS` and `CXXFLAGS` settings.
(This was opposed to adding `$(CFLAGS)` in an ad-hoc manner to various
parts of the mk files.)
Fix #13805.
----
Note that if you try to set the compiler to clang via the `CC` and
`CXX` environment variables, you will probably need to also set
`CXXFLAGS` to `--enable-libcpp` so that LLVM will be configured
properly.
----
Introduce CFG_USING_CLANG, which is distinguished from
CFG_ENABLE_CLANG because the former represents "we think we're using
clang, choose appropriate warning-control options" while the latter
represents "we asked configure (or the host required) that we attempt
to use clang, so check that we have an appropriate version of clang."
The main reason I added this is that I wanted to allow the user to
choose clang via setting the `CC` environment variable, but I did not
want that method of selection to get confused with the user passing
the `--enable-clang` option.
----
A digression: The `configure` script does not infer the compiler
setting if `CC` is set; but if `--enable-clang` was passed, then it
*does* still attempt to validate that the clang version is compatible.
Supporting this required revising `CLANG_VERSION` check to be robust
in face of user-provided `CC` value.
In particular, on Travis, the `CC` is set to `gcc` and so the natural
thing to do is to attempt to use `gcc` as the compiler, but Travis is
also passing `--enable-clang` to configure. So, what is the right
answer in the face of these contradictory requests?
One approach would be to have `--enable-clang` supersede the setting
for `CC` (and instead just call whatever we inferred for `CFG_CLANG`).
That sounds maximally inflexible to me (pnkfelix): a developer
requesting a `CC` value probably wants it respected, and should be
able to set it to something else; it is harder for that developer to
hack our configure script to change its inferred path to clang.
A second approach would be to blindly use the `CC` value but keep
going through the clang version check when `--enable-clang` is turned
on. But on Travis (a Linux host), the `gcc` invocation won't print a
clang version, so we would not get past the CLANG_VERSION check in
that context.
A third approach would be to never run the CLANG_VERSION check if `CC`
is explicitly set. That is not a terrible idea; but if the user uses
`CC` to pass in a path to some other version of clang that they want
to test, probably should still send that through the `CLANG_VERSION`
check.
So in the end I (pnkfelix) took a fourth approach: do the
CLANG_VERSION check if `CC` is unset *or* if `CC` is set to a string
ending with `clang`. This way setting `CC` to things like
`path/to/clang` or `ccache clang` will still go through the
CLANG_VERSION check, while setting `CC` to `gcc` or some unknown
compiler will skip the CLANG_VERSION check (regardless of whether the
user passed --enable-clang to `configure`).
----
Drive-by fixes:
* The call that sets `CFG_CLANG_VERSION` was quoting `"$CFG_CC"` in
its invocation, but that does not play nicely with someone who sets
`$CFG_CC` to e.g. `ccache clang`, since you do not want to intepret
that whole string as a command.
(On the other hand, a path with spaces might need the quoted
invocation. Not sure which one of these corner use-cases is more
important to support.)
* Fix chk_cc error message to point user at `gcc` not `cc`.
2014-04-28 16:57:26 +00:00
|
|
|
define SET_FROM_CFG
|
|
|
|
|
ifdef CFG_$(1)
|
|
|
|
|
ifeq ($(origin $(1)),undefined)
|
2015-12-13 17:19:27 +00:00
|
|
|
$$(info cfg: using $(1)=$$(CFG_$(1)) (CFG_$(1)))
|
|
|
|
|
$(1)=$$(CFG_$(1))
|
|
|
|
|
else ifeq ($(origin $(1)),default)
|
|
|
|
|
$$(info cfg: using $(1)=$$(CFG_$(1)) (CFG_$(1)))
|
|
|
|
|
$(1)=$$(CFG_$(1))
|
Make configure respect (and save) values for `CC`, `CXX`, `CFLAGS`, etc.
I mostly tried to remain backwards compatible with old invocations of
the `configure` script; if you do not want to use `CC` et al., you
should not have to; you can keep using `--enable-clang` and/or
`--enable-ccache`.
The overall intention is to capture the following precedences for
guessing the C compiler:
1. Value of `CC` at make invocation time.
2. Value of `CC` at configure invocation time.
3. Compiler inferred at configure invocation time (`gcc` or `clang`).
The strategy is to check (at `configure` time) if each of the
environment variables is set, and if so, save its value in a
corresponding `CFG_` variable (e.g. `CFG_CC`).
Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we
use the `CFG_CC` setting as `CC`.
Also, I fold the potential user-provided `CFLAGS` and `CXXFLAGS`
values into all of the per-platform `CFLAGS` and `CXXFLAGS` settings.
(This was opposed to adding `$(CFLAGS)` in an ad-hoc manner to various
parts of the mk files.)
Fix #13805.
----
Note that if you try to set the compiler to clang via the `CC` and
`CXX` environment variables, you will probably need to also set
`CXXFLAGS` to `--enable-libcpp` so that LLVM will be configured
properly.
----
Introduce CFG_USING_CLANG, which is distinguished from
CFG_ENABLE_CLANG because the former represents "we think we're using
clang, choose appropriate warning-control options" while the latter
represents "we asked configure (or the host required) that we attempt
to use clang, so check that we have an appropriate version of clang."
The main reason I added this is that I wanted to allow the user to
choose clang via setting the `CC` environment variable, but I did not
want that method of selection to get confused with the user passing
the `--enable-clang` option.
----
A digression: The `configure` script does not infer the compiler
setting if `CC` is set; but if `--enable-clang` was passed, then it
*does* still attempt to validate that the clang version is compatible.
Supporting this required revising `CLANG_VERSION` check to be robust
in face of user-provided `CC` value.
In particular, on Travis, the `CC` is set to `gcc` and so the natural
thing to do is to attempt to use `gcc` as the compiler, but Travis is
also passing `--enable-clang` to configure. So, what is the right
answer in the face of these contradictory requests?
One approach would be to have `--enable-clang` supersede the setting
for `CC` (and instead just call whatever we inferred for `CFG_CLANG`).
That sounds maximally inflexible to me (pnkfelix): a developer
requesting a `CC` value probably wants it respected, and should be
able to set it to something else; it is harder for that developer to
hack our configure script to change its inferred path to clang.
A second approach would be to blindly use the `CC` value but keep
going through the clang version check when `--enable-clang` is turned
on. But on Travis (a Linux host), the `gcc` invocation won't print a
clang version, so we would not get past the CLANG_VERSION check in
that context.
A third approach would be to never run the CLANG_VERSION check if `CC`
is explicitly set. That is not a terrible idea; but if the user uses
`CC` to pass in a path to some other version of clang that they want
to test, probably should still send that through the `CLANG_VERSION`
check.
So in the end I (pnkfelix) took a fourth approach: do the
CLANG_VERSION check if `CC` is unset *or* if `CC` is set to a string
ending with `clang`. This way setting `CC` to things like
`path/to/clang` or `ccache clang` will still go through the
CLANG_VERSION check, while setting `CC` to `gcc` or some unknown
compiler will skip the CLANG_VERSION check (regardless of whether the
user passed --enable-clang to `configure`).
----
Drive-by fixes:
* The call that sets `CFG_CLANG_VERSION` was quoting `"$CFG_CC"` in
its invocation, but that does not play nicely with someone who sets
`$CFG_CC` to e.g. `ccache clang`, since you do not want to intepret
that whole string as a command.
(On the other hand, a path with spaces might need the quoted
invocation. Not sure which one of these corner use-cases is more
important to support.)
* Fix chk_cc error message to point user at `gcc` not `cc`.
2014-04-28 16:57:26 +00:00
|
|
|
endif
|
2013-03-07 06:36:20 +00:00
|
|
|
endif
|
Make configure respect (and save) values for `CC`, `CXX`, `CFLAGS`, etc.
I mostly tried to remain backwards compatible with old invocations of
the `configure` script; if you do not want to use `CC` et al., you
should not have to; you can keep using `--enable-clang` and/or
`--enable-ccache`.
The overall intention is to capture the following precedences for
guessing the C compiler:
1. Value of `CC` at make invocation time.
2. Value of `CC` at configure invocation time.
3. Compiler inferred at configure invocation time (`gcc` or `clang`).
The strategy is to check (at `configure` time) if each of the
environment variables is set, and if so, save its value in a
corresponding `CFG_` variable (e.g. `CFG_CC`).
Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we
use the `CFG_CC` setting as `CC`.
Also, I fold the potential user-provided `CFLAGS` and `CXXFLAGS`
values into all of the per-platform `CFLAGS` and `CXXFLAGS` settings.
(This was opposed to adding `$(CFLAGS)` in an ad-hoc manner to various
parts of the mk files.)
Fix #13805.
----
Note that if you try to set the compiler to clang via the `CC` and
`CXX` environment variables, you will probably need to also set
`CXXFLAGS` to `--enable-libcpp` so that LLVM will be configured
properly.
----
Introduce CFG_USING_CLANG, which is distinguished from
CFG_ENABLE_CLANG because the former represents "we think we're using
clang, choose appropriate warning-control options" while the latter
represents "we asked configure (or the host required) that we attempt
to use clang, so check that we have an appropriate version of clang."
The main reason I added this is that I wanted to allow the user to
choose clang via setting the `CC` environment variable, but I did not
want that method of selection to get confused with the user passing
the `--enable-clang` option.
----
A digression: The `configure` script does not infer the compiler
setting if `CC` is set; but if `--enable-clang` was passed, then it
*does* still attempt to validate that the clang version is compatible.
Supporting this required revising `CLANG_VERSION` check to be robust
in face of user-provided `CC` value.
In particular, on Travis, the `CC` is set to `gcc` and so the natural
thing to do is to attempt to use `gcc` as the compiler, but Travis is
also passing `--enable-clang` to configure. So, what is the right
answer in the face of these contradictory requests?
One approach would be to have `--enable-clang` supersede the setting
for `CC` (and instead just call whatever we inferred for `CFG_CLANG`).
That sounds maximally inflexible to me (pnkfelix): a developer
requesting a `CC` value probably wants it respected, and should be
able to set it to something else; it is harder for that developer to
hack our configure script to change its inferred path to clang.
A second approach would be to blindly use the `CC` value but keep
going through the clang version check when `--enable-clang` is turned
on. But on Travis (a Linux host), the `gcc` invocation won't print a
clang version, so we would not get past the CLANG_VERSION check in
that context.
A third approach would be to never run the CLANG_VERSION check if `CC`
is explicitly set. That is not a terrible idea; but if the user uses
`CC` to pass in a path to some other version of clang that they want
to test, probably should still send that through the `CLANG_VERSION`
check.
So in the end I (pnkfelix) took a fourth approach: do the
CLANG_VERSION check if `CC` is unset *or* if `CC` is set to a string
ending with `clang`. This way setting `CC` to things like
`path/to/clang` or `ccache clang` will still go through the
CLANG_VERSION check, while setting `CC` to `gcc` or some unknown
compiler will skip the CLANG_VERSION check (regardless of whether the
user passed --enable-clang to `configure`).
----
Drive-by fixes:
* The call that sets `CFG_CLANG_VERSION` was quoting `"$CFG_CC"` in
its invocation, but that does not play nicely with someone who sets
`$CFG_CC` to e.g. `ccache clang`, since you do not want to intepret
that whole string as a command.
(On the other hand, a path with spaces might need the quoted
invocation. Not sure which one of these corner use-cases is more
important to support.)
* Fix chk_cc error message to point user at `gcc` not `cc`.
2014-04-28 16:57:26 +00:00
|
|
|
endef
|
|
|
|
|
|
2014-07-23 04:45:08 +00:00
|
|
|
$(foreach cvar,CC CXX CPP CFLAGS CXXFLAGS CPPFLAGS, \
|
Make configure respect (and save) values for `CC`, `CXX`, `CFLAGS`, etc.
I mostly tried to remain backwards compatible with old invocations of
the `configure` script; if you do not want to use `CC` et al., you
should not have to; you can keep using `--enable-clang` and/or
`--enable-ccache`.
The overall intention is to capture the following precedences for
guessing the C compiler:
1. Value of `CC` at make invocation time.
2. Value of `CC` at configure invocation time.
3. Compiler inferred at configure invocation time (`gcc` or `clang`).
The strategy is to check (at `configure` time) if each of the
environment variables is set, and if so, save its value in a
corresponding `CFG_` variable (e.g. `CFG_CC`).
Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we
use the `CFG_CC` setting as `CC`.
Also, I fold the potential user-provided `CFLAGS` and `CXXFLAGS`
values into all of the per-platform `CFLAGS` and `CXXFLAGS` settings.
(This was opposed to adding `$(CFLAGS)` in an ad-hoc manner to various
parts of the mk files.)
Fix #13805.
----
Note that if you try to set the compiler to clang via the `CC` and
`CXX` environment variables, you will probably need to also set
`CXXFLAGS` to `--enable-libcpp` so that LLVM will be configured
properly.
----
Introduce CFG_USING_CLANG, which is distinguished from
CFG_ENABLE_CLANG because the former represents "we think we're using
clang, choose appropriate warning-control options" while the latter
represents "we asked configure (or the host required) that we attempt
to use clang, so check that we have an appropriate version of clang."
The main reason I added this is that I wanted to allow the user to
choose clang via setting the `CC` environment variable, but I did not
want that method of selection to get confused with the user passing
the `--enable-clang` option.
----
A digression: The `configure` script does not infer the compiler
setting if `CC` is set; but if `--enable-clang` was passed, then it
*does* still attempt to validate that the clang version is compatible.
Supporting this required revising `CLANG_VERSION` check to be robust
in face of user-provided `CC` value.
In particular, on Travis, the `CC` is set to `gcc` and so the natural
thing to do is to attempt to use `gcc` as the compiler, but Travis is
also passing `--enable-clang` to configure. So, what is the right
answer in the face of these contradictory requests?
One approach would be to have `--enable-clang` supersede the setting
for `CC` (and instead just call whatever we inferred for `CFG_CLANG`).
That sounds maximally inflexible to me (pnkfelix): a developer
requesting a `CC` value probably wants it respected, and should be
able to set it to something else; it is harder for that developer to
hack our configure script to change its inferred path to clang.
A second approach would be to blindly use the `CC` value but keep
going through the clang version check when `--enable-clang` is turned
on. But on Travis (a Linux host), the `gcc` invocation won't print a
clang version, so we would not get past the CLANG_VERSION check in
that context.
A third approach would be to never run the CLANG_VERSION check if `CC`
is explicitly set. That is not a terrible idea; but if the user uses
`CC` to pass in a path to some other version of clang that they want
to test, probably should still send that through the `CLANG_VERSION`
check.
So in the end I (pnkfelix) took a fourth approach: do the
CLANG_VERSION check if `CC` is unset *or* if `CC` is set to a string
ending with `clang`. This way setting `CC` to things like
`path/to/clang` or `ccache clang` will still go through the
CLANG_VERSION check, while setting `CC` to `gcc` or some unknown
compiler will skip the CLANG_VERSION check (regardless of whether the
user passed --enable-clang to `configure`).
----
Drive-by fixes:
* The call that sets `CFG_CLANG_VERSION` was quoting `"$CFG_CC"` in
its invocation, but that does not play nicely with someone who sets
`$CFG_CC` to e.g. `ccache clang`, since you do not want to intepret
that whole string as a command.
(On the other hand, a path with spaces might need the quoted
invocation. Not sure which one of these corner use-cases is more
important to support.)
* Fix chk_cc error message to point user at `gcc` not `cc`.
2014-04-28 16:57:26 +00:00
|
|
|
$(eval $(call SET_FROM_CFG,$(cvar))))
|
|
|
|
|
|
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 22:03:29 +00:00
|
|
|
CFG_RLIB_GLOB=lib$(1)-*.rlib
|
2013-03-07 06:36:20 +00:00
|
|
|
|
2014-11-19 19:53:18 +00:00
|
|
|
include $(wildcard $(CFG_SRC_DIR)mk/cfg/*.mk)
|
2014-05-23 21:16:21 +00:00
|
|
|
|
2015-05-11 19:29:08 +00:00
|
|
|
define ADD_INSTALLED_OBJECTS
|
2015-11-08 01:44:44 +00:00
|
|
|
INSTALLED_OBJECTS_$(1) += $$(CFG_INSTALLED_OBJECTS_$(1))
|
2015-12-13 17:19:27 +00:00
|
|
|
ifdef CFG_THIRD_PARTY_OBJECTS_$(1)
|
|
|
|
|
REQUIRED_OBJECTS_$(1) += $$(CFG_THIRD_PARTY_OBJECTS_$(1))
|
|
|
|
|
endif
|
2015-07-27 20:41:35 +00:00
|
|
|
INSTALLED_OBJECTS_$(1) += $$(call CFG_STATIC_LIB_NAME_$(1),compiler-rt)
|
2015-11-08 01:44:44 +00:00
|
|
|
REQUIRED_OBJECTS_$(1) += $$(call CFG_STATIC_LIB_NAME_$(1),compiler-rt)
|
2015-05-11 19:29:08 +00:00
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
$(foreach target,$(CFG_TARGET), \
|
|
|
|
|
$(eval $(call ADD_INSTALLED_OBJECTS,$(target))))
|
|
|
|
|
|
2015-05-26 16:48:24 +00:00
|
|
|
define DEFINE_LINKER
|
|
|
|
|
ifndef LINK_$(1)
|
|
|
|
|
LINK_$(1) := $$(CC_$(1))
|
|
|
|
|
endif
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
$(foreach target,$(CFG_TARGET), \
|
|
|
|
|
$(eval $(call DEFINE_LINKER,$(target))))
|
|
|
|
|
|
2014-05-23 21:16:21 +00:00
|
|
|
# The -Qunused-arguments sidesteps spurious warnings from clang
|
|
|
|
|
define FILTER_FLAGS
|
|
|
|
|
ifeq ($$(CFG_USING_CLANG),1)
|
|
|
|
|
ifneq ($(findstring clang,$$(shell $(CC_$(1)) -v)),)
|
|
|
|
|
CFG_GCCISH_CFLAGS_$(1) += -Qunused-arguments
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_$(1) += -Qunused-arguments
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
endef
|
|
|
|
|
|
2014-07-23 04:45:08 +00:00
|
|
|
$(foreach target,$(CFG_TARGET), \
|
2014-05-23 21:16:21 +00:00
|
|
|
$(eval $(call FILTER_FLAGS,$(target))))
|
|
|
|
|
|
2015-05-11 21:07:42 +00:00
|
|
|
# Configure various macros to pass gcc or cl.exe style arguments
|
|
|
|
|
define CC_MACROS
|
|
|
|
|
CFG_CC_INCLUDE_$(1)=-I $$(1)
|
|
|
|
|
ifeq ($$(findstring msvc,$(1)),msvc)
|
|
|
|
|
CFG_CC_OUTPUT_$(1)=-Fo:$$(1)
|
|
|
|
|
CFG_CREATE_ARCHIVE_$(1)=$$(AR_$(1)) -OUT:$$(1)
|
|
|
|
|
else
|
|
|
|
|
CFG_CC_OUTPUT_$(1)=-o $$(1)
|
|
|
|
|
CFG_CREATE_ARCHIVE_$(1)=$$(AR_$(1)) crus $$(1)
|
|
|
|
|
endif
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
$(foreach target,$(CFG_TARGET), \
|
|
|
|
|
$(eval $(call CC_MACROS,$(target))))
|
|
|
|
|
|
2014-05-23 21:16:21 +00:00
|
|
|
|
2013-05-29 21:18:09 +00:00
|
|
|
ifeq ($(CFG_CCACHE_CPP2),1)
|
|
|
|
|
CCACHE_CPP2=1
|
|
|
|
|
export CCACHE_CPP
|
|
|
|
|
endif
|
2013-03-01 11:02:29 +00:00
|
|
|
|
2013-05-30 14:26:12 +00:00
|
|
|
ifdef CFG_CCACHE_BASEDIR
|
|
|
|
|
CCACHE_BASEDIR=$(CFG_CCACHE_BASEDIR)
|
|
|
|
|
export CCACHE_BASEDIR
|
|
|
|
|
endif
|
|
|
|
|
|
2014-04-19 20:18:25 +00:00
|
|
|
FIND_COMPILER = $(word 1,$(1:ccache=))
|
|
|
|
|
|
2013-03-07 06:36:20 +00:00
|
|
|
define CFG_MAKE_TOOLCHAIN
|
2013-11-20 06:30:51 +00:00
|
|
|
# Prepend the tools with their prefix if cross compiling
|
|
|
|
|
ifneq ($(CFG_BUILD),$(1))
|
2015-05-11 21:08:46 +00:00
|
|
|
ifneq ($$(findstring msvc,$(1)),msvc)
|
2015-12-13 17:19:27 +00:00
|
|
|
CC_$(1)=$(CROSS_PREFIX_$(1))$(CC_$(1))
|
|
|
|
|
CXX_$(1)=$(CROSS_PREFIX_$(1))$(CXX_$(1))
|
|
|
|
|
CPP_$(1)=$(CROSS_PREFIX_$(1))$(CPP_$(1))
|
|
|
|
|
AR_$(1)=$(CROSS_PREFIX_$(1))$(AR_$(1))
|
|
|
|
|
LINK_$(1)=$(CROSS_PREFIX_$(1))$(LINK_$(1))
|
|
|
|
|
RUSTC_CROSS_FLAGS_$(1)=-C linker=$$(call FIND_COMPILER,$$(LINK_$(1))) \
|
|
|
|
|
-C ar=$$(call FIND_COMPILER,$$(AR_$(1))) $(RUSTC_CROSS_FLAGS_$(1))
|
|
|
|
|
|
|
|
|
|
RUSTC_FLAGS_$(1)=$$(RUSTC_CROSS_FLAGS_$(1)) $(RUSTC_FLAGS_$(1))
|
2015-05-11 21:08:46 +00:00
|
|
|
endif
|
2013-11-20 06:30:51 +00:00
|
|
|
endif
|
|
|
|
|
|
2014-07-23 04:37:05 +00:00
|
|
|
CFG_COMPILE_C_$(1) = $$(CC_$(1)) \
|
2015-11-20 14:48:19 +00:00
|
|
|
$$(CFLAGS) \
|
2014-07-23 04:37:05 +00:00
|
|
|
$$(CFG_GCCISH_CFLAGS) \
|
2013-02-27 05:53:35 +00:00
|
|
|
$$(CFG_GCCISH_CFLAGS_$(1)) \
|
2015-05-11 21:07:42 +00:00
|
|
|
-c $$(call CFG_CC_OUTPUT_$(1),$$(1)) $$(2)
|
2013-03-07 06:36:20 +00:00
|
|
|
CFG_LINK_C_$(1) = $$(CC_$(1)) \
|
2015-11-20 14:48:19 +00:00
|
|
|
$$(LDFLAGS) \
|
2014-07-23 04:37:05 +00:00
|
|
|
$$(CFG_GCCISH_LINK_FLAGS) -o $$(1) \
|
|
|
|
|
$$(CFG_GCCISH_LINK_FLAGS_$(1)) \
|
|
|
|
|
$$(CFG_GCCISH_DEF_FLAG_$(1))$$(3) $$(2) \
|
2013-02-27 05:53:35 +00:00
|
|
|
$$(call CFG_INSTALL_NAME_$(1),$$(4))
|
2013-03-07 06:36:20 +00:00
|
|
|
CFG_COMPILE_CXX_$(1) = $$(CXX_$(1)) \
|
2015-11-20 14:48:19 +00:00
|
|
|
$$(CXXFLAGS) \
|
2014-07-23 04:37:05 +00:00
|
|
|
$$(CFG_GCCISH_CFLAGS) \
|
|
|
|
|
$$(CFG_GCCISH_CXXFLAGS) \
|
2013-02-27 05:53:35 +00:00
|
|
|
$$(CFG_GCCISH_CFLAGS_$(1)) \
|
2014-07-23 04:37:05 +00:00
|
|
|
$$(CFG_GCCISH_CXXFLAGS_$(1)) \
|
2015-05-11 21:07:42 +00:00
|
|
|
-c $$(call CFG_CC_OUTPUT_$(1),$$(1)) $$(2)
|
2013-03-07 06:36:20 +00:00
|
|
|
CFG_LINK_CXX_$(1) = $$(CXX_$(1)) \
|
2015-11-20 14:48:19 +00:00
|
|
|
$$(LDFLAGS) \
|
2014-07-23 04:37:05 +00:00
|
|
|
$$(CFG_GCCISH_LINK_FLAGS) -o $$(1) \
|
|
|
|
|
$$(CFG_GCCISH_LINK_FLAGS_$(1)) \
|
|
|
|
|
$$(CFG_GCCISH_DEF_FLAG_$(1))$$(3) $$(2) \
|
2013-02-27 05:53:35 +00:00
|
|
|
$$(call CFG_INSTALL_NAME_$(1),$$(4))
|
|
|
|
|
|
2015-01-10 03:52:58 +00:00
|
|
|
ifeq ($$(findstring $(HOST_$(1)),arm aarch64 mips mipsel powerpc),)
|
2013-02-27 05:53:35 +00:00
|
|
|
|
2015-03-28 15:09:51 +00:00
|
|
|
# On Bitrig, we need the relocation model to be PIC for everything
|
2015-01-17 07:51:04 +00:00
|
|
|
ifeq (,$(filter $(OSTYPE_$(1)),bitrig))
|
|
|
|
|
LLVM_MC_RELOCATION_MODEL="pic"
|
|
|
|
|
else
|
|
|
|
|
LLVM_MC_RELOCATION_MODEL="default"
|
|
|
|
|
endif
|
|
|
|
|
|
2013-03-07 06:36:20 +00:00
|
|
|
# We're using llvm-mc as our assembler because it supports
|
|
|
|
|
# .cfi pseudo-ops on mac
|
2015-05-11 19:27:26 +00:00
|
|
|
CFG_ASSEMBLE_$(1)=$$(CPP_$(1)) -E $$(2) | \
|
2013-10-21 09:18:21 +00:00
|
|
|
$$(LLVM_MC_$$(CFG_BUILD)) \
|
2011-12-10 00:02:50 +00:00
|
|
|
-assemble \
|
2015-01-17 07:51:04 +00:00
|
|
|
-relocation-model=$$(LLVM_MC_RELOCATION_MODEL) \
|
2011-12-10 00:02:50 +00:00
|
|
|
-filetype=obj \
|
|
|
|
|
-triple=$(1) \
|
|
|
|
|
-o=$$(1)
|
2013-02-27 05:53:35 +00:00
|
|
|
else
|
|
|
|
|
|
2015-01-10 03:52:58 +00:00
|
|
|
# For the ARM, AARCH64, MIPS and POWER crosses, use the toolchain assembler
|
2014-01-26 08:43:42 +00:00
|
|
|
# FIXME: We should be able to use the LLVM assembler
|
2013-10-17 08:40:33 +00:00
|
|
|
CFG_ASSEMBLE_$(1)=$$(CC_$(1)) $$(CFG_GCCISH_CFLAGS_$(1)) \
|
2015-05-11 19:27:26 +00:00
|
|
|
$$(2) -c -o $$(1)
|
2013-02-27 05:53:35 +00:00
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
|
2011-12-10 00:02:50 +00:00
|
|
|
endef
|
|
|
|
|
|
2014-07-23 04:45:08 +00:00
|
|
|
$(foreach target,$(CFG_TARGET), \
|
2013-03-07 06:36:20 +00:00
|
|
|
$(eval $(call CFG_MAKE_TOOLCHAIN,$(target))))
|