rust/mk/platform.mk

669 lines
29 KiB
Makefile
Raw Normal View History

# 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.
# Create variables HOST_<triple> containing the host part
# of each target triple. For example, the triple i686-darwin-macos
# would create a variable HOST_i686-darwin-macos with the value
# 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))))
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
OS_SUPP = $(patsubst %,--suppressions=%,\
$(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
# 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 \
--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
CFG_PERF_TOOL :=\
$(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
$(foreach cvar,CC CXX CPP CFLAGS CXXFLAGS CPPFLAGS,\
$(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
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
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
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 =
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
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
# 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)
CFG_LIB_NAME_i686-unknown-linux-gnu=lib$(1).so
CFG_STATIC_LIB_NAME_i686-unknown-linux-gnu=lib$(1).a
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)
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=
CFG_GCCISH_PRE_LIB_FLAGS_i686-unknown-linux-gnu := -Wl,-whole-archive
CFG_GCCISH_POST_LIB_FLAGS_i686-unknown-linux-gnu := -Wl,-no-whole-archive
CFG_DEF_SUFFIX_i686-unknown-linux-gnu := .linux.def
2014-01-04 08:34:15 +01:00
CFG_LLC_FLAGS_i686-unknown-linux-gnu :=
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))
# arm-apple-ios configuration
CFG_SDK_NAME_arm-apple-ios = iphoneos
CFG_SDK_ARCHS_arm-apple-ios = armv7
ifneq ($(findstring darwin,$(CFG_OSTYPE)),)
CFG_IOS_SDK = $(shell xcrun --show-sdk-path -sdk iphoneos 2>/dev/null)
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
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
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)
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)
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
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
# 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)
CFG_LIB_NAME_i686-apple-darwin=lib$(1).dylib
CFG_STATIC_LIB_NAME_i686-apple-darwin=lib$(1).a
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)
CFG_GCCISH_LINK_FLAGS_i686-apple-darwin := -dynamiclib -pthread -framework CoreServices -m32
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 :=
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))
# 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
AR_arm-linux-androideabi=$(CFG_ANDROID_CROSS_PATH)/bin/arm-linux-androideabi-ar
CFG_LIB_NAME_arm-linux-androideabi=lib$(1).so
CFG_STATIC_LIB_NAME_arm-linux-androideabi=lib$(1).a
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)
CFG_GCCISH_LINK_FLAGS_arm-linux-androideabi := -shared -fPIC -ldl -g -lm -lsupc++
CFG_GCCISH_DEF_FLAG_arm-linux-androideabi := -Wl,--export-dynamic,--dynamic-list=
CFG_GCCISH_PRE_LIB_FLAGS_arm-linux-androideabi := -Wl,-whole-archive
CFG_GCCISH_POST_LIB_FLAGS_arm-linux-androideabi := -Wl,-no-whole-archive
CFG_DEF_SUFFIX_arm-linux-androideabi := .android.def
CFG_LLC_FLAGS_arm-linux-androideabi :=
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 :=
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
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
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
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++
CPP_mipsel-linux=mipsel-linux-gcc
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
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
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-01 12:02:29 +01:00
# i686-pc-mingw32 configuration
2013-03-07 07:36:20 +01:00
CC_i686-pc-mingw32=$(CC)
CXX_i686-pc-mingw32=$(CXX)
CPP_i686-pc-mingw32=$(CPP)
AR_i686-pc-mingw32=$(AR)
2013-03-02 05:51:10 +01:00
CFG_LIB_NAME_i686-pc-mingw32=$(1).dll
CFG_STATIC_LIB_NAME_i686-pc-mingw32=$(1).lib
2013-03-02 05:51:10 +01:00
CFG_LIB_GLOB_i686-pc-mingw32=$(1)-*.dll
CFG_LIB_DSYM_GLOB_i686-pc-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_mips-i686-pc-mingw32 := -m32 -march=i686 -D_WIN32_WINNT=0x0600 $(CFLAGS)
CFG_GCCISH_CFLAGS_i686-pc-mingw32 := -Wall -Werror -g -m32 -march=i686 -D_WIN32_WINNT=0x0600 -I$(CFG_SRC_DIR)src/etc/mingw-fix-include $(CFLAGS)
CFG_GCCISH_CXXFLAGS_i686-pc-mingw32 := -fno-rtti $(CXXFLAGS)
CFG_GCCISH_LINK_FLAGS_i686-pc-mingw32 := -shared -fPIC -g -m32
2013-03-01 12:02:29 +01:00
CFG_GCCISH_DEF_FLAG_i686-pc-mingw32 :=
CFG_GCCISH_PRE_LIB_FLAGS_i686-pc-mingw32 :=
CFG_GCCISH_POST_LIB_FLAGS_i686-pc-mingw32 :=
CFG_DEF_SUFFIX_i686-pc-mingw32 := .mingw32.def
2014-01-04 08:34:15 +01:00
CFG_LLC_FLAGS_i686-pc-mingw32 :=
2013-03-01 12:02:29 +01:00
CFG_INSTALL_NAME_i686-pc-mingw32 =
2013-11-20 07:30:51 +01:00
CFG_LIBUV_LINK_FLAGS_i686-pc-mingw32 := -lws2_32 -lpsapi -liphlpapi
CFG_LLVM_BUILD_ENV_i686-pc-mingw32 := CPATH=$(CFG_SRC_DIR)src/etc/mingw-fix-include
CFG_EXE_SUFFIX_i686-pc-mingw32 := .exe
CFG_WINDOWSY_i686-pc-mingw32 := 1
2013-03-04 08:48:27 +01:00
CFG_UNIXY_i686-pc-mingw32 :=
CFG_PATH_MUNGE_i686-pc-mingw32 :=
CFG_LDPATH_i686-pc-mingw32 :=$(CFG_LDPATH_i686-pc-mingw32):$(PATH)
CFG_RUN_i686-pc-mingw32=PATH="$(CFG_LDPATH_i686-pc-mingw32):$(1)" $(2)
2013-10-21 11:18:21 +02:00
CFG_RUN_TARG_i686-pc-mingw32=$(call CFG_RUN_i686-pc-mingw32,$(HLIB$(1)_H_$(CFG_BUILD)),$(2))
RUSTC_FLAGS_i686-pc-mingw32=-C link-args="-Wl,--large-address-aware"
# i586-mingw32msvc configuration
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
CFG_LIB_NAME_i586-mingw32msvc=$(1).dll
CFG_STATIC_LIB_NAME_i586-mingw32msvc=$(1).lib
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)
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 :=
CFG_INSTALL_NAME_i586-mingw32msvc =
CFG_LIBUV_LINK_FLAGS_i586-mingw32msvc := -L$(CFG_MINGW32_CROSS_PATH)/i586-mingw32msvc/lib -lws2_32 -lpsapi -liphlpapi
CFG_EXE_SUFFIX_i586-mingw32msvc := .exe
CFG_WINDOWSY_i586-mingw32msvc := 1
2013-03-04 08:48:27 +01:00
CFG_UNIXY_i586-mingw32msvc :=
CFG_PATH_MUNGE_i586-mingw32msvc := $(strip perl -i.bak -p \
-e 's@\\(\S)@/\1@go;' \
-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
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-w64-mingw32 := -march=i586 -m32 -D_WIN32_WINNT=0x0600 $(CFLAGS)
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-02-11 22:51:08 +01:00
RUSTC_CROSS_FLAGS_i686-w64-mingw32 :=
2013-11-20 07:30:51 +01: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
CFG_LIB_NAME_x86_64-w64-mingw32=$(1).dll
CFG_STATIC_LIB_NAME_x86_64-w64-mingw32=$(1).lib
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
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 :=
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
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 :=
# 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)
CFG_LIB_NAME_x86_64-unknown-freebsd=lib$(1).so
CFG_STATIC_LIB_NAME_x86_64-unknown-freebsd=lib$(1).a
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)
CFG_GCCISH_LINK_FLAGS_x86_64-unknown-freebsd := -shared -fPIC -g -pthread -lrt
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 :=
CFG_INSTALL_NAME_x86_64-unknown-freebsd =
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))
# 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
$(foreach target,$(CFG_TARGET),\
$(eval $(call FILTER_FLAGS,$(target))))
ifeq ($(CFG_CCACHE_CPP2),1)
CCACHE_CPP2=1
export CCACHE_CPP
endif
2013-03-01 12:02:29 +01:00
ifdef CFG_CCACHE_BASEDIR
CCACHE_BASEDIR=$(CFG_CCACHE_BASEDIR)
export CCACHE_BASEDIR
endif
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))
RUSTC_CROSS_FLAGS_$(1)=-C linker=$$(call FIND_COMPILER,$$(CXX_$(1))) \
-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
2013-03-07 07:36:20 +01:00
CFG_COMPILE_C_$(1) = $$(CC_$(1)) \
2013-02-27 06:53:35 +01:00
$$(CFG_GCCISH_CFLAGS) \
$$(CFG_GCCISH_CFLAGS_$(1)) \
$$(CFG_DEPEND_FLAGS) \
-c -o $$(1) $$(2)
2013-03-07 07:36:20 +01:00
CFG_LINK_C_$(1) = $$(CC_$(1)) \
2013-02-27 06:53:35 +01:00
$$(CFG_GCCISH_LINK_FLAGS) -o $$(1) \
$$(CFG_GCCISH_LINK_FLAGS_$(1)) \
2013-02-27 06:53:35 +01:00
$$(CFG_GCCISH_DEF_FLAG_$(1))$$(3) $$(2) \
$$(call CFG_INSTALL_NAME_$(1),$$(4))
2013-03-07 07:36:20 +01:00
CFG_COMPILE_CXX_$(1) = $$(CXX_$(1)) \
2013-02-27 06:53:35 +01:00
$$(CFG_GCCISH_CFLAGS) \
$$(CFG_GCCISH_CXXFLAGS) \
$$(CFG_GCCISH_CFLAGS_$(1)) \
$$(CFG_GCCISH_CXXFLAGS_$(1)) \
$$(CFG_DEPEND_FLAGS) \
-c -o $$(1) $$(2)
2013-03-07 07:36:20 +01:00
CFG_LINK_CXX_$(1) = $$(CXX_$(1)) \
2013-02-27 06:53:35 +01:00
$$(CFG_GCCISH_LINK_FLAGS) -o $$(1) \
$$(CFG_GCCISH_LINK_FLAGS_$(1)) \
$$(CFG_GCCISH_DEF_FLAG_$(1))$$(3) $$(2) \
$$(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)) \
-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
# FIXME: We should be able to use the LLVM assembler
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
endef
2013-10-21 11:18:21 +02:00
$(foreach target,$(CFG_TARGET),\
2013-03-07 07:36:20 +01:00
$(eval $(call CFG_MAKE_TOOLCHAIN,$(target))))