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.
|
|
|
|
|
|
2011-05-04 03:09:18 +02:00
|
|
|
|
2011-11-02 00:50:47 +01:00
|
|
|
# Create variables HOST_<triple> containing the host part
|
|
|
|
|
# of each target triple. For example, the triple i686-darwin-macos
|
2013-05-04 01:25:04 +02:00
|
|
|
# would create a variable HOST_i686-darwin-macos with the value
|
2011-11-02 00:50:47 +01:00
|
|
|
# i386.
|
|
|
|
|
define DEF_HOST_VAR
|
|
|
|
|
HOST_$(1) = $(subst i686,i386,$(word 1,$(subst -, ,$(1))))
|
|
|
|
|
endef
|
2013-10-21 11:18:21 +02: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-02 00:50:47 +01:00
|
|
|
|
2013-02-22 04:10:16 +01:00
|
|
|
# Ditto for OSTYPE
|
|
|
|
|
define DEF_OSTYPE_VAR
|
|
|
|
|
OSTYPE_$(1) = $(subst $(firstword $(subst -, ,$(1)))-,,$(1))
|
|
|
|
|
endef
|
2013-10-21 11:18:21 +02: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 04:10:16 +01:00
|
|
|
|
2011-05-01 22:18:52 +02: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 07:36:20 +01:00
|
|
|
# Hack: not sure how to test if a file exists in make other than this
|
2014-07-23 06:45:08 +02:00
|
|
|
OS_SUPP = $(patsubst %,--suppressions=%, \
|
2013-03-07 07:36:20 +01: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-17 00:25:01 +02: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 07:36:20 +01:00
|
|
|
ifdef CFG_VALGRIND
|
|
|
|
|
CFG_VALGRIND += --error-exitcode=100 \
|
2013-09-17 00:25:01 +02:00
|
|
|
--soname-synonyms=somalloc=NONE \
|
2013-03-07 07:36:20 +01:00
|
|
|
--quiet \
|
|
|
|
|
--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
|
|
|
|
|
|
|
|
|
|
ifneq ($(findstring linux,$(CFG_OSTYPE)),)
|
|
|
|
|
ifdef CFG_PERF
|
|
|
|
|
ifneq ($(CFG_PERF_WITH_LOGFD),)
|
|
|
|
|
CFG_PERF_TOOL := $(CFG_PERF) stat -r 3 --log-fd 2
|
|
|
|
|
else
|
|
|
|
|
CFG_PERF_TOOL := $(CFG_PERF) stat -r 3
|
|
|
|
|
endif
|
|
|
|
|
else
|
|
|
|
|
ifdef CFG_VALGRIND
|
2014-07-23 06:45:08 +02:00
|
|
|
CFG_PERF_TOOL := \
|
2013-03-07 07:36:20 +01:00
|
|
|
$(CFG_VALGRIND) --tool=cachegrind --cache-sim=yes --branch-sim=yes
|
|
|
|
|
else
|
|
|
|
|
CFG_PERF_TOOL := /usr/bin/time --verbose
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# These flags will cause the compiler to produce a .d file
|
|
|
|
|
# next to the .o file that lists header deps.
|
|
|
|
|
CFG_DEPEND_FLAGS = -MMD -MP -MT $(1) -MF $(1:%.o=%.d)
|
|
|
|
|
|
|
|
|
|
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 18:57:26 +02:00
|
|
|
define SET_FROM_CFG
|
|
|
|
|
ifdef CFG_$(1)
|
|
|
|
|
ifeq ($(origin $(1)),undefined)
|
|
|
|
|
$$(info cfg: using $(1)=$(CFG_$(1)) (CFG_$(1)))
|
|
|
|
|
$(1)=$(CFG_$(1))
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(origin $(1)),default)
|
|
|
|
|
$$(info cfg: using $(1)=$(CFG_$(1)) (CFG_$(1)))
|
|
|
|
|
$(1)=$(CFG_$(1))
|
|
|
|
|
endif
|
2013-03-07 07:36:20 +01: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 18:57:26 +02:00
|
|
|
endef
|
|
|
|
|
|
2014-07-23 06:45:08 +02: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 18:57:26 +02: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 23:03:29 +01:00
|
|
|
CFG_RLIB_GLOB=lib$(1)-*.rlib
|
2013-03-07 07:36:20 +01:00
|
|
|
|
2013-03-01 12:02:29 +01:00
|
|
|
# x86_64-unknown-linux-gnu configuration
|
2013-03-07 07:36:20 +01:00
|
|
|
CC_x86_64-unknown-linux-gnu=$(CC)
|
|
|
|
|
CXX_x86_64-unknown-linux-gnu=$(CXX)
|
|
|
|
|
CPP_x86_64-unknown-linux-gnu=$(CPP)
|
|
|
|
|
AR_x86_64-unknown-linux-gnu=$(AR)
|
2013-02-27 06:53:35 +01:00
|
|
|
CFG_LIB_NAME_x86_64-unknown-linux-gnu=lib$(1).so
|
2013-10-08 18:20:17 +02:00
|
|
|
CFG_STATIC_LIB_NAME_x86_64-unknown-linux-gnu=lib$(1).a
|
2013-02-27 06:53:35 +01:00
|
|
|
CFG_LIB_GLOB_x86_64-unknown-linux-gnu=lib$(1)-*.so
|
|
|
|
|
CFG_LIB_DSYM_GLOB_x86_64-unknown-linux-gnu=lib$(1)-*.dylib.dSYM
|
2014-05-11 03:22:12 +02:00
|
|
|
CFG_CFLAGS_x86_64-unknown-linux-gnu := -m64
|
2013-02-27 06:53:35 +01:00
|
|
|
CFG_GCCISH_CFLAGS_x86_64-unknown-linux-gnu := -Wall -Werror -g -fPIC -m64
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_x86_64-unknown-linux-gnu := -fno-rtti
|
2013-06-06 01:37:14 +02:00
|
|
|
CFG_GCCISH_LINK_FLAGS_x86_64-unknown-linux-gnu := -shared -fPIC -ldl -pthread -lrt -g -m64
|
2013-02-27 06:53:35 +01:00
|
|
|
CFG_GCCISH_DEF_FLAG_x86_64-unknown-linux-gnu := -Wl,--export-dynamic,--dynamic-list=
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_x86_64-unknown-linux-gnu := -Wl,-whole-archive
|
2013-03-31 22:22:05 +02:00
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_x86_64-unknown-linux-gnu := -Wl,-no-whole-archive
|
2013-02-27 06:53:35 +01:00
|
|
|
CFG_DEF_SUFFIX_x86_64-unknown-linux-gnu := .linux.def
|
2014-01-04 08:34:15 +01:00
|
|
|
CFG_LLC_FLAGS_x86_64-unknown-linux-gnu :=
|
2013-02-27 06:53:35 +01:00
|
|
|
CFG_INSTALL_NAME_x86_64-unknown-linux-gnu =
|
2013-03-02 13:25:12 +01:00
|
|
|
CFG_LIBUV_LINK_FLAGS_x86_64-unknown-linux-gnu =
|
|
|
|
|
CFG_EXE_SUFFIX_x86_64-unknown-linux-gnu =
|
|
|
|
|
CFG_WINDOWSY_x86_64-unknown-linux-gnu :=
|
2013-03-04 08:48:27 +01:00
|
|
|
CFG_UNIXY_x86_64-unknown-linux-gnu := 1
|
2013-03-02 13:25:12 +01:00
|
|
|
CFG_PATH_MUNGE_x86_64-unknown-linux-gnu := true
|
|
|
|
|
CFG_LDPATH_x86_64-unknown-linux-gnu :=
|
|
|
|
|
CFG_RUN_x86_64-unknown-linux-gnu=$(2)
|
|
|
|
|
CFG_RUN_TARG_x86_64-unknown-linux-gnu=$(call CFG_RUN_x86_64-unknown-linux-gnu,,$(2))
|
2013-02-27 06:53:35 +01:00
|
|
|
|
2013-03-04 04:46:27 +01:00
|
|
|
# i686-unknown-linux-gnu configuration
|
2013-03-07 07:36:20 +01:00
|
|
|
CC_i686-unknown-linux-gnu=$(CC)
|
|
|
|
|
CXX_i686-unknown-linux-gnu=$(CXX)
|
|
|
|
|
CPP_i686-unknown-linux-gnu=$(CPP)
|
|
|
|
|
AR_i686-unknown-linux-gnu=$(AR)
|
2013-03-04 04:46:27 +01:00
|
|
|
CFG_LIB_NAME_i686-unknown-linux-gnu=lib$(1).so
|
2013-10-08 18:20:17 +02:00
|
|
|
CFG_STATIC_LIB_NAME_i686-unknown-linux-gnu=lib$(1).a
|
2013-03-04 04:46:27 +01:00
|
|
|
CFG_LIB_GLOB_i686-unknown-linux-gnu=lib$(1)-*.so
|
|
|
|
|
CFG_LIB_DSYM_GLOB_i686-unknown-linux-gnu=lib$(1)-*.dylib.dSYM
|
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 18:57:26 +02:00
|
|
|
CFG_CFLAGS_i686-unknown-linux-gnu := -m32 $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_i686-unknown-linux-gnu := -Wall -Werror -g -fPIC -m32 $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_i686-unknown-linux-gnu := -fno-rtti $(CXXFLAGS)
|
2013-06-06 01:37:14 +02:00
|
|
|
CFG_GCCISH_LINK_FLAGS_i686-unknown-linux-gnu := -shared -fPIC -ldl -pthread -lrt -g -m32
|
2013-03-04 06:23:20 +01:00
|
|
|
CFG_GCCISH_DEF_FLAG_i686-unknown-linux-gnu := -Wl,--export-dynamic,--dynamic-list=
|
2013-03-04 04:46:27 +01:00
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_i686-unknown-linux-gnu := -Wl,-whole-archive
|
2013-03-31 22:22:05 +02:00
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_i686-unknown-linux-gnu := -Wl,-no-whole-archive
|
2013-03-04 04:46:27 +01:00
|
|
|
CFG_DEF_SUFFIX_i686-unknown-linux-gnu := .linux.def
|
2014-01-04 08:34:15 +01:00
|
|
|
CFG_LLC_FLAGS_i686-unknown-linux-gnu :=
|
2013-03-04 04:46:27 +01:00
|
|
|
CFG_INSTALL_NAME_i686-unknown-linux-gnu =
|
2013-03-04 06:23:20 +01:00
|
|
|
CFG_LIBUV_LINK_FLAGS_i686-unknown-linux-gnu =
|
|
|
|
|
CFG_EXE_SUFFIX_i686-unknown-linux-gnu =
|
|
|
|
|
CFG_WINDOWSY_i686-unknown-linux-gnu :=
|
2013-03-04 08:48:27 +01:00
|
|
|
CFG_UNIXY_i686-unknown-linux-gnu := 1
|
2013-03-04 06:23:20 +01:00
|
|
|
CFG_PATH_MUNGE_i686-unknown-linux-gnu := true
|
|
|
|
|
CFG_LDPATH_i686-unknown-linux-gnu :=
|
|
|
|
|
CFG_RUN_i686-unknown-linux-gnu=$(2)
|
|
|
|
|
CFG_RUN_TARG_i686-unknown-linux-gnu=$(call CFG_RUN_i686-unknown-linux-gnu,,$(2))
|
2013-03-04 04:46:27 +01:00
|
|
|
|
2014-05-05 09:05:11 +02:00
|
|
|
# arm-apple-ios configuration
|
|
|
|
|
CFG_SDK_NAME_arm-apple-ios = iphoneos
|
|
|
|
|
CFG_SDK_ARCHS_arm-apple-ios = armv7
|
|
|
|
|
ifneq ($(findstring darwin,$(CFG_OSTYPE)),)
|
2013-11-01 19:39:35 +01:00
|
|
|
CFG_IOS_SDK = $(shell xcrun --show-sdk-path -sdk iphoneos 2>/dev/null)
|
2014-05-05 09:05:11 +02:00
|
|
|
CFG_IOS_FLAGS = -target armv7-apple-darwin -isysroot $(CFG_IOS_SDK) -mios-version-min=7.0
|
|
|
|
|
CC_arm-apple-ios = $(shell xcrun -find -sdk iphoneos clang)
|
|
|
|
|
CXX_arm-apple-ios = $(shell xcrun -find -sdk iphoneos clang++)
|
|
|
|
|
CPP_arm-apple-ios = $(shell xcrun -find -sdk iphoneos clang++)
|
|
|
|
|
AR_arm-apple-ios = $(shell xcrun -find -sdk iphoneos ar)
|
2013-10-31 20:36:27 +01:00
|
|
|
endif
|
2014-05-05 09:05:11 +02:00
|
|
|
CFG_LIB_NAME_arm-apple-ios = lib$(1).a
|
|
|
|
|
CFG_LIB_GLOB_arm-apple-ios = lib$(1)-*.a
|
|
|
|
|
CFG_STATIC_LIB_NAME_arm-apple-ios=lib$(1).a
|
|
|
|
|
CFG_LIB_DSYM_GLOB_arm-apple-ios = lib$(1)-*.a.dSYM
|
|
|
|
|
CFG_CFLAGS_arm-apple-ios := -arch armv7 -mfpu=vfp3 $(CFG_IOS_FLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_arm-apple-ios := -Wall -Werror -g -fPIC $(CFG_IOS_FLAGS) -mfpu=vfp3 -arch armv7
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_arm-apple-ios := -fno-rtti $(CFG_IOS_FLAGS) -I$(CFG_IOS_SDK)/usr/include/c++/4.2.1
|
|
|
|
|
CFG_GCCISH_LINK_FLAGS_arm-apple-ios := -lpthread -syslibroot $(CFG_IOS_SDK) -Wl,-no_compact_unwind
|
|
|
|
|
CFG_GCCISH_DEF_FLAG_arm-apple-ios := -Wl,-exported_symbols_list,
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_arm-apple-ios :=
|
|
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_arm-apple-ios :=
|
|
|
|
|
CFG_DEF_SUFFIX_arm-apple-ios := .darwin.def
|
|
|
|
|
CFG_LLC_FLAGS_arm-apple-ios := -mattr=+vfp3,+v7,+thumb2,+neon -march=arm
|
|
|
|
|
CFG_INSTALL_NAME_arm-apple-ios = -Wl,-install_name,@rpath/$(1)
|
|
|
|
|
CFG_LIBUV_LINK_FLAGS_arm-apple-ios =
|
|
|
|
|
CFG_EXE_SUFFIX_arm-apple-ios :=
|
|
|
|
|
CFG_WINDOWSY_arm-apple-ios :=
|
|
|
|
|
CFG_UNIXY_arm-apple-ios := 1
|
|
|
|
|
CFG_PATH_MUNGE_arm-apple-ios := true
|
|
|
|
|
CFG_LDPATH_arm-apple-ios :=
|
|
|
|
|
CFG_RUN_arm-apple-ios = $(2)
|
|
|
|
|
CFG_RUN_TARG_arm-apple-ios = $(call CFG_RUN_arm-apple-ios,,$(2))
|
|
|
|
|
RUSTC_FLAGS_arm-apple-ios := -C relocation_model=pic
|
|
|
|
|
RUSTC_CROSS_FLAGS_arm-apple-ios :=-C relocation_model=pic
|
|
|
|
|
|
|
|
|
|
# i386-apple-ios configuration
|
|
|
|
|
CFG_SDK_NAME_i386-apple-ios = iphonesimulator
|
|
|
|
|
CFG_SDK_ARCHS_i386-apple-ios = i386
|
|
|
|
|
ifneq ($(findstring darwin,$(CFG_OSTYPE)),)
|
|
|
|
|
CFG_IOSSIM_SDK = $(shell xcrun --show-sdk-path -sdk iphonesimulator 2>/dev/null)
|
|
|
|
|
CFG_IOSSIM_FLAGS = -target i386-apple-ios -isysroot $(CFG_IOSSIM_SDK) -mios-simulator-version-min=7.0
|
|
|
|
|
CC_i386-apple-ios = $(shell xcrun -find -sdk iphonesimulator clang)
|
|
|
|
|
CXX_i386-apple-ios = $(shell xcrun -find -sdk iphonesimulator clang++)
|
|
|
|
|
CPP_i386-apple-ios = $(shell xcrun -find -sdk iphonesimulator clang++)
|
|
|
|
|
AR_i386-apple-ios = $(shell xcrun -find -sdk iphonesimulator ar)
|
|
|
|
|
endif
|
|
|
|
|
CFG_LIB_NAME_i386-apple-ios = lib$(1).a
|
|
|
|
|
CFG_LIB_GLOB_i386-apple-ios = lib$(1)-*.dylib
|
|
|
|
|
CFG_STATIC_LIB_NAME_i386-apple-ios=lib$(1).a
|
|
|
|
|
CFG_LIB_DSYM_GLOB_i386-apple-ios = lib$(1)-*.dylib.dSYM
|
|
|
|
|
CFG_CFLAGS_i386-apple-ios = $(CFG_IOSSIM_FLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_i386-apple-ios = -Wall -Werror -g -fPIC -m32 $(CFG_IOSSIM_FLAGS)
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_i386-apple-ios = -fno-rtti $(CFG_IOSSIM_FLAGS) -I$(CFG_IOSSIM_SDK)/usr/include/c++/4.2.1
|
|
|
|
|
CFG_GCCISH_LINK_FLAGS_i386-apple-ios = -lpthread -Wl,-no_compact_unwind -m32 -Wl,-syslibroot $(CFG_IOSSIM_SDK)
|
|
|
|
|
CFG_GCCISH_DEF_FLAG_i386-apple-ios = -Wl,-exported_symbols_list,
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_i386-apple-ios =
|
|
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_i386-apple-ios =
|
|
|
|
|
CFG_DEF_SUFFIX_i386-apple-ios = .darwin.def
|
|
|
|
|
CFG_LLC_FLAGS_i386-apple-ios =
|
|
|
|
|
CFG_INSTALL_NAME_i386-apple-ios = -Wl,-install_name,@rpath/$(1)
|
|
|
|
|
CFG_LIBUV_LINK_FLAGS_i386-apple-ios =
|
|
|
|
|
CFG_EXE_SUFFIX_i386-apple-ios =
|
|
|
|
|
CFG_WINDOWSY_i386-apple-ios =
|
|
|
|
|
CFG_UNIXY_i386-apple-ios = 1
|
|
|
|
|
CFG_PATH_MUNGE_i386-apple-ios = true
|
|
|
|
|
CFG_LDPATH_i386-apple-ios =
|
|
|
|
|
CFG_RUN_i386-apple-ios = $(2)
|
|
|
|
|
CFG_RUN_TARG_i386-apple-ios = $(call CFG_RUN_i386-apple-ios,,$(2))
|
|
|
|
|
CFG_JEMALLOC_CFLAGS_i386-apple-ios = -target i386-apple-ios -Wl,-syslibroot $(CFG_IOSSIM_SDK) -Wl,-no_compact_unwind
|
2013-10-31 20:36:27 +01:00
|
|
|
|
2013-03-01 12:02:29 +01:00
|
|
|
# x86_64-apple-darwin configuration
|
2013-03-07 07:36:20 +01:00
|
|
|
CC_x86_64-apple-darwin=$(CC)
|
|
|
|
|
CXX_x86_64-apple-darwin=$(CXX)
|
|
|
|
|
CPP_x86_64-apple-darwin=$(CPP)
|
|
|
|
|
AR_x86_64-apple-darwin=$(AR)
|
2013-02-27 06:53:35 +01:00
|
|
|
CFG_LIB_NAME_x86_64-apple-darwin=lib$(1).dylib
|
2013-10-08 18:20:17 +02:00
|
|
|
CFG_STATIC_LIB_NAME_x86_64-apple-darwin=lib$(1).a
|
2013-02-27 06:53:35 +01:00
|
|
|
CFG_LIB_GLOB_x86_64-apple-darwin=lib$(1)-*.dylib
|
|
|
|
|
CFG_LIB_DSYM_GLOB_x86_64-apple-darwin=lib$(1)-*.dylib.dSYM
|
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 18:57:26 +02:00
|
|
|
CFG_CFLAGS_x86_64-apple-darwin := -m64 -arch x86_64 $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_x86_64-apple-darwin := -Wall -Werror -g -fPIC -m64 -arch x86_64 $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_x86_64-apple-darwin := -fno-rtti $(CXXFLAGS)
|
2013-10-22 11:50:52 +02:00
|
|
|
CFG_GCCISH_LINK_FLAGS_x86_64-apple-darwin := -dynamiclib -pthread -framework CoreServices -m64
|
2013-02-27 06:53:35 +01:00
|
|
|
CFG_GCCISH_DEF_FLAG_x86_64-apple-darwin := -Wl,-exported_symbols_list,
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_x86_64-apple-darwin :=
|
|
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_x86_64-apple-darwin :=
|
|
|
|
|
CFG_DEF_SUFFIX_x86_64-apple-darwin := .darwin.def
|
2014-01-04 08:34:15 +01:00
|
|
|
CFG_LLC_FLAGS_x86_64-apple-darwin :=
|
2013-02-27 06:53:35 +01:00
|
|
|
CFG_INSTALL_NAME_x86_64-apple-darwin = -Wl,-install_name,@rpath/$(1)
|
2013-03-02 13:25:12 +01:00
|
|
|
CFG_LIBUV_LINK_FLAGS_x86_64-apple-darwin =
|
|
|
|
|
CFG_EXE_SUFFIX_x86_64-apple-darwin :=
|
|
|
|
|
CFG_WINDOWSY_x86_64-apple-darwin :=
|
2013-03-04 08:48:27 +01:00
|
|
|
CFG_UNIXY_x86_64-apple-darwin := 1
|
2013-03-02 13:25:12 +01:00
|
|
|
CFG_PATH_MUNGE_x86_64-apple-darwin := true
|
|
|
|
|
CFG_LDPATH_x86_64-apple-darwin :=
|
|
|
|
|
CFG_RUN_x86_64-apple-darwin=$(2)
|
|
|
|
|
CFG_RUN_TARG_x86_64-apple-darwin=$(call CFG_RUN_x86_64-apple-darwin,,$(2))
|
2013-02-27 06:53:35 +01:00
|
|
|
|
2013-03-04 04:46:27 +01:00
|
|
|
# i686-apple-darwin configuration
|
2013-03-07 07:36:20 +01:00
|
|
|
CC_i686-apple-darwin=$(CC)
|
|
|
|
|
CXX_i686-apple-darwin=$(CXX)
|
|
|
|
|
CPP_i686-apple-darwin=$(CPP)
|
|
|
|
|
AR_i686-apple-darwin=$(AR)
|
2013-03-04 04:46:27 +01:00
|
|
|
CFG_LIB_NAME_i686-apple-darwin=lib$(1).dylib
|
2013-10-08 18:20:17 +02:00
|
|
|
CFG_STATIC_LIB_NAME_i686-apple-darwin=lib$(1).a
|
2013-03-04 04:46:27 +01:00
|
|
|
CFG_LIB_GLOB_i686-apple-darwin=lib$(1)-*.dylib
|
|
|
|
|
CFG_LIB_DSYM_GLOB_i686-apple-darwin=lib$(1)-*.dylib.dSYM
|
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 18:57:26 +02:00
|
|
|
CFG_CFLAGS_i686-apple-darwin := -m32 -arch i386 $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_i686-apple-darwin := -Wall -Werror -g -fPIC -m32 -arch i386 $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_i686-apple-darwin := -fno-rtti $(CXXFLAGS)
|
2013-10-22 11:50:52 +02:00
|
|
|
CFG_GCCISH_LINK_FLAGS_i686-apple-darwin := -dynamiclib -pthread -framework CoreServices -m32
|
2013-03-04 04:46:27 +01:00
|
|
|
CFG_GCCISH_DEF_FLAG_i686-apple-darwin := -Wl,-exported_symbols_list,
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_i686-apple-darwin :=
|
|
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_i686-apple-darwin :=
|
|
|
|
|
CFG_DEF_SUFFIX_i686-apple-darwin := .darwin.def
|
2014-01-04 08:34:15 +01:00
|
|
|
CFG_LLC_FLAGS_i686-apple-darwin :=
|
2013-03-04 04:46:27 +01:00
|
|
|
CFG_INSTALL_NAME_i686-apple-darwin = -Wl,-install_name,@rpath/$(1)
|
2013-03-04 06:23:20 +01:00
|
|
|
CFG_LIBUV_LINK_FLAGS_i686-apple-darwin =
|
|
|
|
|
CFG_EXE_SUFFIX_i686-apple-darwin :=
|
|
|
|
|
CFG_WINDOWSY_i686-apple-darwin :=
|
2013-03-04 08:48:27 +01:00
|
|
|
CFG_UNIXY_i686-apple-darwin := 1
|
2013-03-04 06:23:20 +01:00
|
|
|
CFG_PATH_MUNGE_i686-apple-darwin := true
|
|
|
|
|
CFG_LDPATH_i686-apple-darwin :=
|
|
|
|
|
CFG_RUN_i686-apple-darwin=$(2)
|
|
|
|
|
CFG_RUN_TARG_i686-apple-darwin=$(call CFG_RUN_i686-apple-darwin,,$(2))
|
2013-03-04 04:46:27 +01:00
|
|
|
|
2013-03-13 01:21:12 +01:00
|
|
|
# arm-linux-androideabi configuration
|
|
|
|
|
CC_arm-linux-androideabi=$(CFG_ANDROID_CROSS_PATH)/bin/arm-linux-androideabi-gcc
|
|
|
|
|
CXX_arm-linux-androideabi=$(CFG_ANDROID_CROSS_PATH)/bin/arm-linux-androideabi-g++
|
2013-08-01 12:39:37 +02:00
|
|
|
CPP_arm-linux-androideabi=$(CFG_ANDROID_CROSS_PATH)/bin/arm-linux-androideabi-gcc -E
|
2013-03-13 01:21:12 +01:00
|
|
|
AR_arm-linux-androideabi=$(CFG_ANDROID_CROSS_PATH)/bin/arm-linux-androideabi-ar
|
|
|
|
|
CFG_LIB_NAME_arm-linux-androideabi=lib$(1).so
|
2013-10-08 18:20:17 +02:00
|
|
|
CFG_STATIC_LIB_NAME_arm-linux-androideabi=lib$(1).a
|
2013-03-13 01:21:12 +01:00
|
|
|
CFG_LIB_GLOB_arm-linux-androideabi=lib$(1)-*.so
|
|
|
|
|
CFG_LIB_DSYM_GLOB_arm-linux-androideabi=lib$(1)-*.dylib.dSYM
|
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 18:57:26 +02:00
|
|
|
CFG_CFLAGS_arm-linux-androideabi := -D__arm__ -DANDROID -D__ANDROID__ $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_arm-linux-androideabi := -Wall -g -fPIC -D__arm__ -DANDROID -D__ANDROID__ $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_arm-linux-androideabi := -fno-rtti $(CXXFLAGS)
|
2013-12-13 08:06:59 +01:00
|
|
|
CFG_GCCISH_LINK_FLAGS_arm-linux-androideabi := -shared -fPIC -ldl -g -lm -lsupc++
|
2013-03-13 01:21:12 +01:00
|
|
|
CFG_GCCISH_DEF_FLAG_arm-linux-androideabi := -Wl,--export-dynamic,--dynamic-list=
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_arm-linux-androideabi := -Wl,-whole-archive
|
2013-03-31 22:22:05 +02:00
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_arm-linux-androideabi := -Wl,-no-whole-archive
|
2013-03-13 01:21:12 +01:00
|
|
|
CFG_DEF_SUFFIX_arm-linux-androideabi := .android.def
|
2014-02-06 20:29:28 +01:00
|
|
|
CFG_LLC_FLAGS_arm-linux-androideabi :=
|
2013-03-13 01:21:12 +01:00
|
|
|
CFG_INSTALL_NAME_arm-linux-androideabi =
|
|
|
|
|
CFG_LIBUV_LINK_FLAGS_arm-linux-androideabi =
|
|
|
|
|
CFG_EXE_SUFFIX_arm-linux-androideabi :=
|
|
|
|
|
CFG_WINDOWSY_arm-linux-androideabi :=
|
|
|
|
|
CFG_UNIXY_arm-linux-androideabi := 1
|
|
|
|
|
CFG_PATH_MUNGE_arm-linux-androideabi := true
|
|
|
|
|
CFG_LDPATH_arm-linux-androideabi :=
|
|
|
|
|
CFG_RUN_arm-linux-androideabi=
|
|
|
|
|
CFG_RUN_TARG_arm-linux-androideabi=
|
2014-02-11 22:51:08 +01:00
|
|
|
RUSTC_FLAGS_arm-linux-androideabi :=
|
2014-05-13 20:44:30 +02:00
|
|
|
RUSTC_CROSS_FLAGS_arm-linux-androideabi :=
|
2013-02-27 06:53:35 +01:00
|
|
|
|
2013-05-05 16:29:10 +02:00
|
|
|
# arm-unknown-linux-gnueabihf configuration
|
2013-11-20 07:30:51 +01:00
|
|
|
CROSS_PREFIX_arm-unknown-linux-gnueabihf=arm-linux-gnueabihf-
|
|
|
|
|
CC_arm-unknown-linux-gnueabihf=gcc
|
|
|
|
|
CXX_arm-unknown-linux-gnueabihf=g++
|
|
|
|
|
CPP_arm-unknown-linux-gnueabihf=gcc -E
|
|
|
|
|
AR_arm-unknown-linux-gnueabihf=ar
|
2013-05-05 16:29:10 +02:00
|
|
|
CFG_LIB_NAME_arm-unknown-linux-gnueabihf=lib$(1).so
|
2013-10-08 18:20:17 +02:00
|
|
|
CFG_STATIC_LIB_NAME_arm-unknown-linux-gnueabihf=lib$(1).a
|
2013-05-05 16:29:10 +02:00
|
|
|
CFG_LIB_GLOB_arm-unknown-linux-gnueabihf=lib$(1)-*.so
|
|
|
|
|
CFG_LIB_DSYM_GLOB_arm-unknown-linux-gnueabihf=lib$(1)-*.dylib.dSYM
|
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 18:57:26 +02:00
|
|
|
CFG_CFLAGS_arm-unknown-linux-gnueabihf := -D__arm__ $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_arm-unknown-linux-gnueabihf := -Wall -g -fPIC -D__arm__ $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_arm-unknown-linux-gnueabihf := -fno-rtti $(CXXFLAGS)
|
2013-05-05 16:29:10 +02:00
|
|
|
CFG_GCCISH_LINK_FLAGS_arm-unknown-linux-gnueabihf := -shared -fPIC -g
|
|
|
|
|
CFG_GCCISH_DEF_FLAG_arm-unknown-linux-gnueabihf := -Wl,--export-dynamic,--dynamic-list=
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_arm-unknown-linux-gnueabihf := -Wl,-whole-archive
|
|
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_arm-unknown-linux-gnueabihf := -Wl,-no-whole-archive
|
|
|
|
|
CFG_DEF_SUFFIX_arm-unknown-linux-gnueabihf := .linux.def
|
2014-02-06 20:29:28 +01:00
|
|
|
CFG_LLC_FLAGS_arm-unknown-linux-gnueabihf :=
|
2013-05-05 16:29:10 +02:00
|
|
|
CFG_INSTALL_NAME_ar,-unknown-linux-gnueabihf =
|
|
|
|
|
CFG_LIBUV_LINK_FLAGS_arm-unknown-linux-gnueabihf =
|
|
|
|
|
CFG_EXE_SUFFIX_arm-unknown-linux-gnueabihf :=
|
|
|
|
|
CFG_WINDOWSY_arm-unknown-linux-gnueabihf :=
|
|
|
|
|
CFG_UNIXY_arm-unknown-linux-gnueabihf := 1
|
|
|
|
|
CFG_PATH_MUNGE_arm-unknown-linux-gnueabihf := true
|
|
|
|
|
CFG_LDPATH_arm-unknown-linux-gnueabihf :=
|
2013-11-20 07:30:51 +01:00
|
|
|
CFG_RUN_arm-unknown-linux-gnueabihf=$(2)
|
|
|
|
|
CFG_RUN_TARG_arm-unknown-linux-gnueabihf=$(call CFG_RUN_arm-unknown-linux-gnueabihf,,$(2))
|
2014-05-06 08:05:05 +02:00
|
|
|
RUSTC_FLAGS_arm-unknown-linux-gnueabihf := -C target-feature=+v6,+vfp2
|
2014-02-11 22:51:08 +01:00
|
|
|
RUSTC_CROSS_FLAGS_arm-unknown-linux-gnueabihf :=
|
2013-05-05 16:29:10 +02:00
|
|
|
|
2013-08-01 12:39:37 +02:00
|
|
|
# arm-unknown-linux-gnueabi configuration
|
2013-11-20 07:30:51 +01:00
|
|
|
CROSS_PREFIX_arm-unknown-linux-gnueabi=arm-linux-gnueabi-
|
|
|
|
|
CC_arm-unknown-linux-gnueabi=gcc
|
|
|
|
|
CXX_arm-unknown-linux-gnueabi=g++
|
|
|
|
|
CPP_arm-unknown-linux-gnueabi=gcc -E
|
|
|
|
|
AR_arm-unknown-linux-gnueabi=ar
|
2013-08-01 12:39:37 +02:00
|
|
|
CFG_LIB_NAME_arm-unknown-linux-gnueabi=lib$(1).so
|
2013-10-08 18:20:17 +02:00
|
|
|
CFG_STATIC_LIB_NAME_arm-unknown-linux-gnueabi=lib$(1).a
|
2013-08-01 12:39:37 +02:00
|
|
|
CFG_LIB_GLOB_arm-unknown-linux-gnueabi=lib$(1)-*.so
|
|
|
|
|
CFG_LIB_DSYM_GLOB_arm-unknown-linux-gnueabi=lib$(1)-*.dylib.dSYM
|
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 18:57:26 +02:00
|
|
|
CFG_CFLAGS_arm-unknown-linux-gnueabi := -D__arm__ -mfpu=vfp $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_arm-unknown-linux-gnueabi := -Wall -g -fPIC -D__arm__ -mfpu=vfp $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_arm-unknown-linux-gnueabi := -fno-rtti $(CXXFLAGS)
|
2013-08-01 12:39:37 +02:00
|
|
|
CFG_GCCISH_LINK_FLAGS_arm-unknown-linux-gnueabi := -shared -fPIC -g
|
|
|
|
|
CFG_GCCISH_DEF_FLAG_arm-unknown-linux-gnueabi := -Wl,--export-dynamic,--dynamic-list=
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_arm-unknown-linux-gnueabi := -Wl,-whole-archive
|
|
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_arm-unknown-linux-gnueabi := -Wl,-no-whole-archive
|
|
|
|
|
CFG_DEF_SUFFIX_arm-unknown-linux-gnueabi := .linux.def
|
2014-02-16 02:08:33 +01:00
|
|
|
CFG_LLC_FLAGS_arm-unknown-linux-gnueabi :=
|
2013-12-11 01:51:46 +01:00
|
|
|
CFG_INSTALL_NAME_arm-unknown-linux-gnueabi =
|
2013-08-01 12:39:37 +02:00
|
|
|
CFG_LIBUV_LINK_FLAGS_arm-unknown-linux-gnueabi =
|
|
|
|
|
CFG_EXE_SUFFIX_arm-unknown-linux-gnueabi :=
|
|
|
|
|
CFG_WINDOWSY_arm-unknown-linux-gnueabi :=
|
|
|
|
|
CFG_UNIXY_arm-unknown-linux-gnueabi := 1
|
|
|
|
|
CFG_PATH_MUNGE_arm-unknown-linux-gnueabi := true
|
|
|
|
|
CFG_LDPATH_arm-unknown-linux-gnueabi :=
|
2013-11-20 07:30:51 +01:00
|
|
|
CFG_RUN_arm-unknown-linux-gnueabi=$(2)
|
|
|
|
|
CFG_RUN_TARG_arm-unknown-linux-gnueabi=$(call CFG_RUN_arm-unknown-linux-gnueabi,,$(2))
|
|
|
|
|
RUSTC_FLAGS_arm-unknown-linux-gnueabi :=
|
2014-02-11 22:51:08 +01:00
|
|
|
RUSTC_CROSS_FLAGS_arm-unknown-linux-gnueabi :=
|
2013-08-01 12:39:37 +02:00
|
|
|
|
2014-06-17 09:16:03 +02:00
|
|
|
# mipsel-linux configuration
|
|
|
|
|
CC_mipsel-linux=mipsel-linux-gcc
|
|
|
|
|
CXX_mipsel-linux=mipsel-linux-g++
|
2014-07-05 09:53:46 +02:00
|
|
|
CPP_mipsel-linux=mipsel-linux-gcc
|
2014-06-17 09:16:03 +02:00
|
|
|
AR_mipsel-linux=mipsel-linux-ar
|
|
|
|
|
CFG_LIB_NAME_mipsel-linux=lib$(1).so
|
|
|
|
|
CFG_STATIC_LIB_NAME_mipsel-linux=lib$(1).a
|
|
|
|
|
CFG_LIB_GLOB_mipsel-linux=lib$(1)-*.so
|
|
|
|
|
CFG_LIB_DSYM_GLOB_mipsel-linux=lib$(1)-*.dylib.dSYM
|
|
|
|
|
CFG_CFLAGS_mipsel-linux := -mips32 -mabi=32 $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_mipsel-linux := -Wall -g -fPIC -mips32 -mabi=32 $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_mipsel-linux := -fno-rtti $(CXXFLAGS)
|
|
|
|
|
CFG_GCCISH_LINK_FLAGS_mipsel-linux := -shared -fPIC -g -mips32
|
|
|
|
|
CFG_GCCISH_DEF_FLAG_mipsel-linux := -Wl,--export-dynamic,--dynamic-list=
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_mipsel-linux := -Wl,-whole-archive
|
|
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_mipsel-linux := -Wl,-no-whole-archive
|
|
|
|
|
CFG_DEF_SUFFIX_mipsel-linux := .linux.def
|
|
|
|
|
CFG_LLC_FLAGS_mipsel-linux :=
|
|
|
|
|
CFG_INSTALL_NAME_mipsel-linux =
|
|
|
|
|
CFG_LIBUV_LINK_FLAGS_mipsel-linux =
|
|
|
|
|
CFG_EXE_SUFFIX_mipsel-linux :=
|
|
|
|
|
CFG_WINDOWSY_mipsel-linux :=
|
|
|
|
|
CFG_UNIXY_mipsel-linux := 1
|
|
|
|
|
CFG_PATH_MUNGE_mipsel-linux := true
|
|
|
|
|
CFG_LDPATH_mipsel-linux :=
|
|
|
|
|
CFG_RUN_mipsel-linux=
|
|
|
|
|
CFG_RUN_TARG_mipsel-linux=
|
|
|
|
|
RUSTC_FLAGS_mipsel-linux := -C target-cpu=mips32 -C target-feature="+mips32,+o32"
|
|
|
|
|
|
|
|
|
|
|
2013-03-19 06:32:03 +01:00
|
|
|
# mips-unknown-linux-gnu configuration
|
|
|
|
|
CC_mips-unknown-linux-gnu=mips-linux-gnu-gcc
|
|
|
|
|
CXX_mips-unknown-linux-gnu=mips-linux-gnu-g++
|
|
|
|
|
CPP_mips-unknown-linux-gnu=mips-linux-gnu-gcc -E
|
|
|
|
|
AR_mips-unknown-linux-gnu=mips-linux-gnu-ar
|
|
|
|
|
CFG_LIB_NAME_mips-unknown-linux-gnu=lib$(1).so
|
2013-10-08 18:20:17 +02:00
|
|
|
CFG_STATIC_LIB_NAME_mips-unknown-linux-gnu=lib$(1).a
|
2013-03-19 06:32:03 +01:00
|
|
|
CFG_LIB_GLOB_mips-unknown-linux-gnu=lib$(1)-*.so
|
|
|
|
|
CFG_LIB_DSYM_GLOB_mips-unknown-linux-gnu=lib$(1)-*.dylib.dSYM
|
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 18:57:26 +02:00
|
|
|
CFG_CFLAGS_mips-unknown-linux-gnu := -mips32r2 -msoft-float -mabi=32 -mno-compact-eh $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_mips-unknown-linux-gnu := -Wall -g -fPIC -mips32r2 -msoft-float -mabi=32 -mno-compact-eh $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_mips-unknown-linux-gnu := -fno-rtti $(CXXFLAGS)
|
2013-03-19 06:32:03 +01:00
|
|
|
CFG_GCCISH_LINK_FLAGS_mips-unknown-linux-gnu := -shared -fPIC -g -mips32r2 -msoft-float -mabi=32
|
|
|
|
|
CFG_GCCISH_DEF_FLAG_mips-unknown-linux-gnu := -Wl,--export-dynamic,--dynamic-list=
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_mips-unknown-linux-gnu := -Wl,-whole-archive
|
2013-05-07 12:03:32 +02:00
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_mips-unknown-linux-gnu := -Wl,-no-whole-archive
|
2013-03-19 06:32:03 +01:00
|
|
|
CFG_DEF_SUFFIX_mips-unknown-linux-gnu := .linux.def
|
2014-01-04 08:34:15 +01:00
|
|
|
CFG_LLC_FLAGS_mips-unknown-linux-gnu :=
|
2013-03-19 06:32:03 +01:00
|
|
|
CFG_INSTALL_NAME_mips-unknown-linux-gnu =
|
|
|
|
|
CFG_LIBUV_LINK_FLAGS_mips-unknown-linux-gnu =
|
|
|
|
|
CFG_EXE_SUFFIX_mips-unknown-linux-gnu :=
|
|
|
|
|
CFG_WINDOWSY_mips-unknown-linux-gnu :=
|
|
|
|
|
CFG_UNIXY_mips-unknown-linux-gnu := 1
|
|
|
|
|
CFG_PATH_MUNGE_mips-unknown-linux-gnu := true
|
|
|
|
|
CFG_LDPATH_mips-unknown-linux-gnu :=
|
|
|
|
|
CFG_RUN_mips-unknown-linux-gnu=
|
|
|
|
|
CFG_RUN_TARG_mips-unknown-linux-gnu=
|
2014-02-11 22:51:08 +01:00
|
|
|
RUSTC_FLAGS_mips-unknown-linux-gnu := -C target-cpu=mips32r2 -C target-feature="+mips32r2,+o32" -C soft-float
|
2013-03-19 06:32:03 +01:00
|
|
|
|
2013-03-02 13:25:12 +01:00
|
|
|
# i586-mingw32msvc configuration
|
2013-03-13 01:21:12 +01:00
|
|
|
CC_i586-mingw32msvc=$(CFG_MINGW32_CROSS_PATH)/bin/i586-mingw32msvc-gcc
|
|
|
|
|
CXX_i586-mingw32msvc=$(CFG_MINGW32_CROSS_PATH)/bin/i586-mingw32msvc-g++
|
|
|
|
|
CPP_i586-mingw32msvc=$(CFG_MINGW32_CROSS_PATH)/bin/i586-mingw32msvc-cpp
|
|
|
|
|
AR_i586-mingw32msvc=$(CFG_MINGW32_CROSS_PATH)/bin/i586-mingw32msvc-ar
|
2013-03-02 13:25:12 +01:00
|
|
|
CFG_LIB_NAME_i586-mingw32msvc=$(1).dll
|
2013-10-08 18:20:17 +02:00
|
|
|
CFG_STATIC_LIB_NAME_i586-mingw32msvc=$(1).lib
|
2013-03-02 13:25:12 +01:00
|
|
|
CFG_LIB_GLOB_i586-mingw32msvc=$(1)-*.dll
|
|
|
|
|
CFG_LIB_DSYM_GLOB_i586-mingw32msvc=$(1)-*.dylib.dSYM
|
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 18:57:26 +02:00
|
|
|
CFG_CFLAGS_i586-mingw32msvc := -march=i586 -m32 $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_i586-mingw32msvc := -Wall -Werror -g -march=i586 -m32 $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_i586-mingw32msvc := -fno-rtti $(CXXFLAGS)
|
2013-03-02 13:25:12 +01:00
|
|
|
CFG_GCCISH_LINK_FLAGS_i586-mingw32msvc := -shared -g -m32
|
|
|
|
|
CFG_GCCISH_DEF_FLAG_i586-mingw32msvc :=
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_i586-mingw32msvc :=
|
|
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_i586-mingw32msvc :=
|
|
|
|
|
CFG_DEF_SUFFIX_i586-mingw32msvc := .mingw32.def
|
2014-01-04 08:34:15 +01:00
|
|
|
CFG_LLC_FLAGS_i586-mingw32msvc :=
|
2013-03-02 13:25:12 +01:00
|
|
|
CFG_INSTALL_NAME_i586-mingw32msvc =
|
2013-03-13 01:21:12 +01:00
|
|
|
CFG_LIBUV_LINK_FLAGS_i586-mingw32msvc := -L$(CFG_MINGW32_CROSS_PATH)/i586-mingw32msvc/lib -lws2_32 -lpsapi -liphlpapi
|
2013-03-02 13:25:12 +01:00
|
|
|
CFG_EXE_SUFFIX_i586-mingw32msvc := .exe
|
|
|
|
|
CFG_WINDOWSY_i586-mingw32msvc := 1
|
2013-03-04 08:48:27 +01:00
|
|
|
CFG_UNIXY_i586-mingw32msvc :=
|
2014-07-23 06:37:05 +02:00
|
|
|
CFG_PATH_MUNGE_i586-mingw32msvc := $(strip perl -i.bak -p \
|
|
|
|
|
-e 's@\\(\S)@/\1@go;' \
|
2013-03-02 13:25:12 +01:00
|
|
|
-e 's@^/([a-zA-Z])/@\1:/@o;')
|
|
|
|
|
CFG_LDPATH_i586-mingw32msvc :=
|
|
|
|
|
CFG_RUN_i586-mingw32msvc=
|
|
|
|
|
CFG_RUN_TARG_i586-mingw32msvc=
|
2013-03-01 12:02:29 +01:00
|
|
|
|
2013-11-20 07:30:51 +01:00
|
|
|
# i686-w64-mingw32 configuration
|
|
|
|
|
CROSS_PREFIX_i686-w64-mingw32=i686-w64-mingw32-
|
|
|
|
|
CC_i686-w64-mingw32=gcc
|
|
|
|
|
CXX_i686-w64-mingw32=g++
|
|
|
|
|
CPP_i686-w64-mingw32=gcc -E
|
|
|
|
|
AR_i686-w64-mingw32=ar
|
|
|
|
|
CFG_LIB_NAME_i686-w64-mingw32=$(1).dll
|
|
|
|
|
CFG_STATIC_LIB_NAME_i686-w64-mingw32=$(1).lib
|
|
|
|
|
CFG_LIB_GLOB_i686-w64-mingw32=$(1)-*.dll
|
|
|
|
|
CFG_LIB_DSYM_GLOB_i686-w64-mingw32=$(1)-*.dylib.dSYM
|
2014-09-12 03:01:07 +02:00
|
|
|
CFG_CFLAGS_i686-w64-mingw32 := -march=i686 -m32 -D_WIN32_WINNT=0x0600 $(CFLAGS)
|
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 18:57:26 +02:00
|
|
|
CFG_GCCISH_CFLAGS_i686-w64-mingw32 := -Wall -Werror -g -m32 -D_WIN32_WINNT=0x0600 $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_i686-w64-mingw32 := -fno-rtti $(CXXFLAGS)
|
2013-11-20 07:30:51 +01:00
|
|
|
CFG_GCCISH_LINK_FLAGS_i686-w64-mingw32 := -shared -g -m32
|
|
|
|
|
CFG_GCCISH_DEF_FLAG_i686-w64-mingw32 :=
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_i686-w64-mingw32 :=
|
|
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_i686-w64-mingw32 :=
|
|
|
|
|
CFG_DEF_SUFFIX_i686-w64-mingw32 := .mingw32.def
|
2014-01-04 08:34:15 +01:00
|
|
|
CFG_LLC_FLAGS_i686-w64-mingw32 :=
|
2013-11-20 07:30:51 +01:00
|
|
|
CFG_INSTALL_NAME_i686-w64-mingw32 =
|
|
|
|
|
CFG_LIBUV_LINK_FLAGS_i686-w64-mingw32 := -lws2_32 -lpsapi -liphlpapi
|
|
|
|
|
CFG_EXE_SUFFIX_i686-w64-mingw32 := .exe
|
|
|
|
|
CFG_WINDOWSY_i686-w64-mingw32 := 1
|
|
|
|
|
CFG_UNIXY_i686-w64-mingw32 :=
|
|
|
|
|
CFG_PATH_MUNGE_i686-w64-mingw32 :=
|
|
|
|
|
CFG_LDPATH_i686-w64-mingw32 :=$(CFG_LDPATH_i686-w64-mingw32):$(PATH)
|
|
|
|
|
CFG_RUN_i686-w64-mingw32=PATH="$(CFG_LDPATH_i686-w64-mingw32):$(1)" $(2)
|
|
|
|
|
CFG_RUN_TARG_i686-w64-mingw32=$(call CFG_RUN_i686-w64-mingw32,$(HLIB$(1)_H_$(CFG_BUILD)),$(2))
|
2014-09-12 03:01:07 +02:00
|
|
|
# Stop rustc from OOMing when building itself (I think)
|
|
|
|
|
RUSTC_FLAGS_i686-w64-mingw32=-C link-args="-Wl,--large-address-aware"
|
2014-02-11 22:51:08 +01:00
|
|
|
RUSTC_CROSS_FLAGS_i686-w64-mingw32 :=
|
2013-11-20 07:30:51 +01:00
|
|
|
|
2013-07-04 05:33:59 +02:00
|
|
|
# x86_64-w64-mingw32 configuration
|
2013-11-20 07:30:51 +01:00
|
|
|
CROSS_PREFIX_x86_64-w64-mingw32=x86_64-w64-mingw32-
|
|
|
|
|
CC_x86_64-w64-mingw32=gcc
|
|
|
|
|
CXX_x86_64-w64-mingw32=g++
|
|
|
|
|
CPP_x86_64-w64-mingw32=gcc -E
|
|
|
|
|
AR_x86_64-w64-mingw32=ar
|
2013-07-04 05:33:59 +02:00
|
|
|
CFG_LIB_NAME_x86_64-w64-mingw32=$(1).dll
|
2013-10-08 18:20:17 +02:00
|
|
|
CFG_STATIC_LIB_NAME_x86_64-w64-mingw32=$(1).lib
|
2013-07-04 05:33:59 +02:00
|
|
|
CFG_LIB_GLOB_x86_64-w64-mingw32=$(1)-*.dll
|
|
|
|
|
CFG_LIB_DSYM_GLOB_x86_64-w64-mingw32=$(1)-*.dylib.dSYM
|
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 18:57:26 +02:00
|
|
|
CFG_CFLAGS_x86_64-w64-mingw32 := -m64 -D_WIN32_WINNT=0x0600 $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_x86_64-w64-mingw32 := -Wall -Werror -g -m64 -D_WIN32_WINNT=0x0600 $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CXXFLAGS_x86_64-w64-mingw32 := -fno-rtti $(CXXFLAGS)
|
2013-11-20 07:30:51 +01:00
|
|
|
CFG_GCCISH_LINK_FLAGS_x86_64-w64-mingw32 := -shared -g -m64
|
2013-07-04 05:33:59 +02:00
|
|
|
CFG_GCCISH_DEF_FLAG_x86_64-w64-mingw32 :=
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_x86_64-w64-mingw32 :=
|
|
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_x86_64-w64-mingw32 :=
|
|
|
|
|
CFG_DEF_SUFFIX_x86_64-w64-mingw32 := .mingw32.def
|
2014-01-04 08:34:15 +01:00
|
|
|
CFG_LLC_FLAGS_x86_64-w64-mingw32 :=
|
2013-07-04 05:33:59 +02:00
|
|
|
CFG_INSTALL_NAME_x86_64-w64-mingw32 =
|
2013-11-20 07:30:51 +01:00
|
|
|
CFG_LIBUV_LINK_FLAGS_x86_64-w64-mingw32 := -lws2_32 -lpsapi -liphlpapi
|
2013-07-04 05:33:59 +02:00
|
|
|
CFG_EXE_SUFFIX_x86_64-w64-mingw32 := .exe
|
|
|
|
|
CFG_WINDOWSY_x86_64-w64-mingw32 := 1
|
|
|
|
|
CFG_UNIXY_x86_64-w64-mingw32 :=
|
|
|
|
|
CFG_PATH_MUNGE_x86_64-w64-mingw32 :=
|
|
|
|
|
CFG_LDPATH_x86_64-w64-mingw32 :=$(CFG_LDPATH_x86_64-w64-mingw32):$(PATH)
|
|
|
|
|
CFG_RUN_x86_64-w64-mingw32=PATH="$(CFG_LDPATH_x86_64-w64-mingw32):$(1)" $(2)
|
2013-10-21 11:18:21 +02:00
|
|
|
CFG_RUN_TARG_x86_64-w64-mingw32=$(call CFG_RUN_x86_64-w64-mingw32,$(HLIB$(1)_H_$(CFG_BUILD)),$(2))
|
2014-02-11 22:51:08 +01:00
|
|
|
RUSTC_CROSS_FLAGS_x86_64-w64-mingw32 :=
|
2013-07-04 05:33:59 +02:00
|
|
|
|
2013-03-04 04:46:27 +01:00
|
|
|
# x86_64-unknown-freebsd configuration
|
2013-03-07 07:36:20 +01:00
|
|
|
CC_x86_64-unknown-freebsd=$(CC)
|
|
|
|
|
CXX_x86_64-unknown-freebsd=$(CXX)
|
|
|
|
|
CPP_x86_64-unknown-freebsd=$(CPP)
|
|
|
|
|
AR_x86_64-unknown-freebsd=$(AR)
|
2013-03-04 04:46:27 +01:00
|
|
|
CFG_LIB_NAME_x86_64-unknown-freebsd=lib$(1).so
|
2013-10-08 18:20:17 +02:00
|
|
|
CFG_STATIC_LIB_NAME_x86_64-unknown-freebsd=lib$(1).a
|
2013-03-04 04:46:27 +01:00
|
|
|
CFG_LIB_GLOB_x86_64-unknown-freebsd=lib$(1)-*.so
|
2013-03-04 06:23:20 +01:00
|
|
|
CFG_LIB_DSYM_GLOB_x86_64-unknown-freebsd=$(1)-*.dylib.dSYM
|
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 18:57:26 +02:00
|
|
|
CFG_CFLAGS_x86_64-unknown-freebsd := -I/usr/local/include $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_x86_64-unknown-freebsd := -Wall -Werror -g -fPIC -I/usr/local/include $(CFLAGS)
|
2013-06-06 01:37:14 +02:00
|
|
|
CFG_GCCISH_LINK_FLAGS_x86_64-unknown-freebsd := -shared -fPIC -g -pthread -lrt
|
2013-03-04 04:46:27 +01:00
|
|
|
CFG_GCCISH_DEF_FLAG_x86_64-unknown-freebsd := -Wl,--export-dynamic,--dynamic-list=
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_x86_64-unknown-freebsd := -Wl,-whole-archive
|
|
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_x86_64-unknown-freebsd := -Wl,-no-whole-archive
|
|
|
|
|
CFG_DEF_SUFFIX_x86_64-unknown-freebsd := .bsd.def
|
2014-01-04 08:34:15 +01:00
|
|
|
CFG_LLC_FLAGS_x86_64-unknown-freebsd :=
|
2013-03-04 04:46:27 +01:00
|
|
|
CFG_INSTALL_NAME_x86_64-unknown-freebsd =
|
2013-06-06 01:37:14 +02:00
|
|
|
CFG_LIBUV_LINK_FLAGS_x86_64-unknown-freebsd := -pthread -lkvm
|
2013-03-04 06:23:20 +01:00
|
|
|
CFG_EXE_SUFFIX_x86_64-unknown-freebsd :=
|
|
|
|
|
CFG_WINDOWSY_x86_64-unknown-freebsd :=
|
2013-03-04 08:48:27 +01:00
|
|
|
CFG_UNIXY_x86_64-unknown-freebsd := 1
|
2013-03-04 06:23:20 +01:00
|
|
|
CFG_PATH_MUNGE_x86_64-unknown-freebsd :=
|
|
|
|
|
CFG_LDPATH_x86_64-unknown-freebsd :=
|
|
|
|
|
CFG_RUN_x86_64-unknown-freebsd=$(2)
|
|
|
|
|
CFG_RUN_TARG_x86_64-unknown-freebsd=$(call CFG_RUN_x86_64-unknown-freebsd,,$(2))
|
2013-03-04 04:46:27 +01:00
|
|
|
|
2014-07-29 16:44:39 +02:00
|
|
|
# x86_64-pc-dragonfly-elf configuration
|
|
|
|
|
CC_x86_64-unknown-dragonfly=$(CC)
|
|
|
|
|
CXX_x86_64-unknown-dragonfly=$(CXX)
|
|
|
|
|
CPP_x86_64-unknown-dragonfly=$(CPP)
|
|
|
|
|
AR_x86_64-unknown-dragonfly=$(AR)
|
|
|
|
|
CFG_LIB_NAME_x86_64-unknown-dragonfly=lib$(1).so
|
|
|
|
|
CFG_STATIC_LIB_NAME_x86_64-unknown-dragonfly=lib$(1).a
|
|
|
|
|
CFG_LIB_GLOB_x86_64-unknown-dragonfly=lib$(1)-*.so
|
|
|
|
|
CFG_LIB_DSYM_GLOB_x86_64-unknown-dragonfly=$(1)-*.dylib.dSYM
|
|
|
|
|
CFG_CFLAGS_x86_64-unknown-dragonfly := -I/usr/include -I/usr/local/include $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_CFLAGS_x86_64-unknown-dragonfly := -Wall -Werror -g -fPIC -I/usr/include -I/usr/local/include $(CFLAGS)
|
|
|
|
|
CFG_GCCISH_LINK_FLAGS_x86_64-unknown-dragonfly := -shared -fPIC -g -pthread -lrt
|
|
|
|
|
CFG_GCCISH_DEF_FLAG_x86_64-unknown-dragonfly := -Wl,--export-dynamic,--dynamic-list=
|
|
|
|
|
CFG_GCCISH_PRE_LIB_FLAGS_x86_64-unknown-dragonfly := -Wl,-whole-archive
|
|
|
|
|
CFG_GCCISH_POST_LIB_FLAGS_x86_64-unknown-dragonfly := -Wl,-no-whole-archive
|
|
|
|
|
CFG_DEF_SUFFIX_x86_64-unknown-dragonfly := .bsd.def
|
|
|
|
|
CFG_LLC_FLAGS_x86_64-unknown-dragonfly :=
|
|
|
|
|
CFG_INSTALL_NAME_x86_64-unknown-dragonfly =
|
|
|
|
|
CFG_LIBUV_LINK_FLAGS_x86_64-unknown-dragonfly := -pthread -lkvm
|
|
|
|
|
CFG_EXE_SUFFIX_x86_64-unknown-dragonfly :=
|
|
|
|
|
CFG_WINDOWSY_x86_64-unknown-dragonfly :=
|
|
|
|
|
CFG_UNIXY_x86_64-unknown-dragonfly := 1
|
|
|
|
|
CFG_PATH_MUNGE_x86_64-unknown-dragonfly :=
|
|
|
|
|
CFG_LDPATH_x86_64-unknown-dragonfly :=
|
|
|
|
|
CFG_RUN_x86_64-unknown-dragonfly=$(2)
|
|
|
|
|
CFG_RUN_TARG_x86_64-unknown-dragonfly=$(call CFG_RUN_x86_64-unknown-dragonfly,,$(2))
|
|
|
|
|
|
2014-05-23 23:16:21 +02: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 06:45:08 +02:00
|
|
|
$(foreach target,$(CFG_TARGET), \
|
2014-05-23 23:16:21 +02:00
|
|
|
$(eval $(call FILTER_FLAGS,$(target))))
|
|
|
|
|
|
|
|
|
|
|
2013-05-29 23:18:09 +02:00
|
|
|
ifeq ($(CFG_CCACHE_CPP2),1)
|
|
|
|
|
CCACHE_CPP2=1
|
|
|
|
|
export CCACHE_CPP
|
|
|
|
|
endif
|
2013-03-01 12:02:29 +01:00
|
|
|
|
2013-05-30 16:26:12 +02:00
|
|
|
ifdef CFG_CCACHE_BASEDIR
|
|
|
|
|
CCACHE_BASEDIR=$(CFG_CCACHE_BASEDIR)
|
|
|
|
|
export CCACHE_BASEDIR
|
|
|
|
|
endif
|
|
|
|
|
|
2014-04-19 22:18:25 +02:00
|
|
|
FIND_COMPILER = $(word 1,$(1:ccache=))
|
|
|
|
|
|
2013-03-07 07:36:20 +01:00
|
|
|
define CFG_MAKE_TOOLCHAIN
|
2013-11-20 07:30:51 +01:00
|
|
|
# Prepend the tools with their prefix if cross compiling
|
|
|
|
|
ifneq ($(CFG_BUILD),$(1))
|
|
|
|
|
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))
|
2014-07-05 09:53:46 +02:00
|
|
|
RUSTC_CROSS_FLAGS_$(1)=-C linker=$$(call FIND_COMPILER,$$(CC_$(1))) \
|
2014-04-19 22:18:25 +02:00
|
|
|
-C ar=$$(call FIND_COMPILER,$$(AR_$(1))) $(RUSTC_CROSS_FLAGS_$(1))
|
2013-11-20 07:30:51 +01:00
|
|
|
|
2014-02-11 22:51:08 +01:00
|
|
|
RUSTC_FLAGS_$(1)=$$(RUSTC_CROSS_FLAGS_$(1)) $(RUSTC_FLAGS_$(1))
|
2013-11-20 07:30:51 +01:00
|
|
|
endif
|
|
|
|
|
|
2014-07-23 06:37:05 +02:00
|
|
|
CFG_COMPILE_C_$(1) = $$(CC_$(1)) \
|
|
|
|
|
$$(CFG_GCCISH_CFLAGS) \
|
2013-02-27 06:53:35 +01:00
|
|
|
$$(CFG_GCCISH_CFLAGS_$(1)) \
|
2014-07-23 06:37:05 +02:00
|
|
|
$$(CFG_DEPEND_FLAGS) \
|
2013-02-27 06:53:35 +01:00
|
|
|
-c -o $$(1) $$(2)
|
2013-03-07 07:36:20 +01:00
|
|
|
CFG_LINK_C_$(1) = $$(CC_$(1)) \
|
2014-07-23 06:37:05 +02:00
|
|
|
$$(CFG_GCCISH_LINK_FLAGS) -o $$(1) \
|
|
|
|
|
$$(CFG_GCCISH_LINK_FLAGS_$(1)) \
|
|
|
|
|
$$(CFG_GCCISH_DEF_FLAG_$(1))$$(3) $$(2) \
|
2013-02-27 06:53:35 +01:00
|
|
|
$$(call CFG_INSTALL_NAME_$(1),$$(4))
|
2013-03-07 07:36:20 +01:00
|
|
|
CFG_COMPILE_CXX_$(1) = $$(CXX_$(1)) \
|
2014-07-23 06:37:05 +02:00
|
|
|
$$(CFG_GCCISH_CFLAGS) \
|
|
|
|
|
$$(CFG_GCCISH_CXXFLAGS) \
|
2013-02-27 06:53:35 +01:00
|
|
|
$$(CFG_GCCISH_CFLAGS_$(1)) \
|
2014-07-23 06:37:05 +02:00
|
|
|
$$(CFG_GCCISH_CXXFLAGS_$(1)) \
|
|
|
|
|
$$(CFG_DEPEND_FLAGS) \
|
2011-11-02 00:50:47 +01:00
|
|
|
-c -o $$(1) $$(2)
|
2013-03-07 07:36:20 +01:00
|
|
|
CFG_LINK_CXX_$(1) = $$(CXX_$(1)) \
|
2014-07-23 06:37:05 +02:00
|
|
|
$$(CFG_GCCISH_LINK_FLAGS) -o $$(1) \
|
|
|
|
|
$$(CFG_GCCISH_LINK_FLAGS_$(1)) \
|
|
|
|
|
$$(CFG_GCCISH_DEF_FLAG_$(1))$$(3) $$(2) \
|
2013-02-27 06:53:35 +01:00
|
|
|
$$(call CFG_INSTALL_NAME_$(1),$$(4))
|
|
|
|
|
|
2014-06-17 09:16:03 +02:00
|
|
|
ifeq ($$(findstring $(HOST_$(1)),arm mips mipsel),)
|
2013-02-27 06:53:35 +01:00
|
|
|
|
2013-03-07 07:36:20 +01:00
|
|
|
# We're using llvm-mc as our assembler because it supports
|
|
|
|
|
# .cfi pseudo-ops on mac
|
|
|
|
|
CFG_ASSEMBLE_$(1)=$$(CPP_$(1)) -E $$(CFG_DEPEND_FLAGS) $$(2) | \
|
2013-10-21 11:18:21 +02:00
|
|
|
$$(LLVM_MC_$$(CFG_BUILD)) \
|
2011-12-10 01:02:50 +01:00
|
|
|
-assemble \
|
|
|
|
|
-filetype=obj \
|
|
|
|
|
-triple=$(1) \
|
|
|
|
|
-o=$$(1)
|
2013-02-27 06:53:35 +01:00
|
|
|
else
|
|
|
|
|
|
2013-09-17 19:58:07 +02:00
|
|
|
# For the ARM and MIPS crosses, use the toolchain assembler
|
2014-01-26 09:43:42 +01:00
|
|
|
# FIXME: We should be able to use the LLVM assembler
|
2013-10-17 10:40:33 +02:00
|
|
|
CFG_ASSEMBLE_$(1)=$$(CC_$(1)) $$(CFG_GCCISH_CFLAGS_$(1)) \
|
|
|
|
|
$$(CFG_DEPEND_FLAGS) $$(2) -c -o $$(1)
|
2013-02-27 06:53:35 +01:00
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
|
2011-12-10 01:02:50 +01:00
|
|
|
endef
|
|
|
|
|
|
2014-07-23 06:45:08 +02:00
|
|
|
$(foreach target,$(CFG_TARGET), \
|
2013-03-07 07:36:20 +01:00
|
|
|
$(eval $(call CFG_MAKE_TOOLCHAIN,$(target))))
|