rust/mk/platform.mk

310 lines
10 KiB
Makefile
Raw Normal View History

# Copyright 2012-2015 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 09:18:21 +00:00
$(foreach t,$(CFG_TARGET),$(eval $(call DEF_HOST_VAR,$(t))))
$(foreach t,$(CFG_TARGET),$(info cfg: host for $(t) is $(HOST_$(t))))
2013-02-22 03:10:16 +00:00
# Ditto for OSTYPE
define DEF_OSTYPE_VAR
OSTYPE_$(1) = $(subst $(firstword $(subst -, ,$(1)))-,,$(1))
endef
2013-10-21 09:18:21 +00:00
$(foreach t,$(CFG_TARGET),$(eval $(call DEF_OSTYPE_VAR,$(t))))
$(foreach t,$(CFG_TARGET),$(info cfg: os for $(t) is $(OSTYPE_$(t))))
2013-02-22 03:10:16 +00:00
2011-05-01 20:18:52 +00:00
# On Darwin, we need to run dsymutil so the debugging information ends
# up in the right place. On other platforms, it automatically gets
# embedded into the executable, so use a no-op command.
CFG_DSYMUTIL := true
2013-03-07 06:36:20 +00:00
# Hack: not sure how to test if a file exists in make other than this
OS_SUPP = $(patsubst %,--suppressions=%, \
2013-03-07 06:36:20 +00:00
$(wildcard $(CFG_SRC_DIR)src/etc/$(CFG_OSTYPE).supp*))
ifdef CFG_DISABLE_OPTIMIZE_CXX
$(info cfg: disabling C++ optimization (CFG_DISABLE_OPTIMIZE_CXX))
CFG_GCCISH_CFLAGS += -O0
else
CFG_GCCISH_CFLAGS += -O2
endif
# The soname thing is for supporting a statically linked jemalloc.
# see https://blog.mozilla.org/jseward/2012/06/05/valgrind-now-supports-jemalloc-builds-directly/
2013-03-07 06:36:20 +00:00
ifdef CFG_VALGRIND
CFG_VALGRIND += --error-exitcode=100 \
--fair-sched=try \
2013-03-07 06:36:20 +00:00
--quiet \
--soname-synonyms=somalloc=NONE \
2013-03-07 06:36:20 +00:00
--suppressions=$(CFG_SRC_DIR)src/etc/x86.supp \
$(OS_SUPP)
ifdef CFG_ENABLE_HELGRIND
CFG_VALGRIND += --tool=helgrind
else
CFG_VALGRIND += --tool=memcheck \
--leak-check=full
endif
endif
# If we actually want to run Valgrind on a given platform, set this variable
define DEF_GOOD_VALGRIND
ifeq ($(OSTYPE_$(1)),unknown-linux-gnu)
GOOD_VALGRIND_$(1) = 1
endif
ifneq (,$(filter $(OSTYPE_$(1)),darwin freebsd))
ifeq (HOST_$(1),x86_64)
GOOD_VALGRIND_$(1) = 1
endif
endif
endef
$(foreach t,$(CFG_TARGET),$(eval $(call DEF_GOOD_VALGRIND,$(t))))
$(foreach t,$(CFG_TARGET),$(info cfg: good valgrind for $(t) is $(GOOD_VALGRIND_$(t))))
2013-03-07 06:36:20 +00:00
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 := \
2013-03-07 06:36:20 +00:00
$(CFG_VALGRIND) --tool=cachegrind --cache-sim=yes --branch-sim=yes
else
CFG_PERF_TOOL := /usr/bin/time --verbose
endif
endif
endif
AR := ar
Make configure respect (and save) values for `CC`, `CXX`, `CFLAGS`, etc. I mostly tried to remain backwards compatible with old invocations of the `configure` script; if you do not want to use `CC` et al., you should not have to; you can keep using `--enable-clang` and/or `--enable-ccache`. The overall intention is to capture the following precedences for guessing the C compiler: 1. Value of `CC` at make invocation time. 2. Value of `CC` at configure invocation time. 3. Compiler inferred at configure invocation time (`gcc` or `clang`). The strategy is to check (at `configure` time) if each of the environment variables is set, and if so, save its value in a corresponding `CFG_` variable (e.g. `CFG_CC`). Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we use the `CFG_CC` setting as `CC`. Also, I fold the potential user-provided `CFLAGS` and `CXXFLAGS` values into all of the per-platform `CFLAGS` and `CXXFLAGS` settings. (This was opposed to adding `$(CFLAGS)` in an ad-hoc manner to various parts of the mk files.) Fix #13805. ---- Note that if you try to set the compiler to clang via the `CC` and `CXX` environment variables, you will probably need to also set `CXXFLAGS` to `--enable-libcpp` so that LLVM will be configured properly. ---- Introduce CFG_USING_CLANG, which is distinguished from CFG_ENABLE_CLANG because the former represents "we think we're using clang, choose appropriate warning-control options" while the latter represents "we asked configure (or the host required) that we attempt to use clang, so check that we have an appropriate version of clang." The main reason I added this is that I wanted to allow the user to choose clang via setting the `CC` environment variable, but I did not want that method of selection to get confused with the user passing the `--enable-clang` option. ---- A digression: The `configure` script does not infer the compiler setting if `CC` is set; but if `--enable-clang` was passed, then it *does* still attempt to validate that the clang version is compatible. Supporting this required revising `CLANG_VERSION` check to be robust in face of user-provided `CC` value. In particular, on Travis, the `CC` is set to `gcc` and so the natural thing to do is to attempt to use `gcc` as the compiler, but Travis is also passing `--enable-clang` to configure. So, what is the right answer in the face of these contradictory requests? One approach would be to have `--enable-clang` supersede the setting for `CC` (and instead just call whatever we inferred for `CFG_CLANG`). That sounds maximally inflexible to me (pnkfelix): a developer requesting a `CC` value probably wants it respected, and should be able to set it to something else; it is harder for that developer to hack our configure script to change its inferred path to clang. A second approach would be to blindly use the `CC` value but keep going through the clang version check when `--enable-clang` is turned on. But on Travis (a Linux host), the `gcc` invocation won't print a clang version, so we would not get past the CLANG_VERSION check in that context. A third approach would be to never run the CLANG_VERSION check if `CC` is explicitly set. That is not a terrible idea; but if the user uses `CC` to pass in a path to some other version of clang that they want to test, probably should still send that through the `CLANG_VERSION` check. So in the end I (pnkfelix) took a fourth approach: do the CLANG_VERSION check if `CC` is unset *or* if `CC` is set to a string ending with `clang`. This way setting `CC` to things like `path/to/clang` or `ccache clang` will still go through the CLANG_VERSION check, while setting `CC` to `gcc` or some unknown compiler will skip the CLANG_VERSION check (regardless of whether the user passed --enable-clang to `configure`). ---- Drive-by fixes: * The call that sets `CFG_CLANG_VERSION` was quoting `"$CFG_CC"` in its invocation, but that does not play nicely with someone who sets `$CFG_CC` to e.g. `ccache clang`, since you do not want to intepret that whole string as a command. (On the other hand, a path with spaces might need the quoted invocation. Not sure which one of these corner use-cases is more important to support.) * Fix chk_cc error message to point user at `gcc` not `cc`.
2014-04-28 16:57:26 +00:00
define SET_FROM_CFG
ifdef CFG_$(1)
ifeq ($(origin $(1)),undefined)
$$(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 06:36:20 +00:00
endif
Make configure respect (and save) values for `CC`, `CXX`, `CFLAGS`, etc. I mostly tried to remain backwards compatible with old invocations of the `configure` script; if you do not want to use `CC` et al., you should not have to; you can keep using `--enable-clang` and/or `--enable-ccache`. The overall intention is to capture the following precedences for guessing the C compiler: 1. Value of `CC` at make invocation time. 2. Value of `CC` at configure invocation time. 3. Compiler inferred at configure invocation time (`gcc` or `clang`). The strategy is to check (at `configure` time) if each of the environment variables is set, and if so, save its value in a corresponding `CFG_` variable (e.g. `CFG_CC`). Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we use the `CFG_CC` setting as `CC`. Also, I fold the potential user-provided `CFLAGS` and `CXXFLAGS` values into all of the per-platform `CFLAGS` and `CXXFLAGS` settings. (This was opposed to adding `$(CFLAGS)` in an ad-hoc manner to various parts of the mk files.) Fix #13805. ---- Note that if you try to set the compiler to clang via the `CC` and `CXX` environment variables, you will probably need to also set `CXXFLAGS` to `--enable-libcpp` so that LLVM will be configured properly. ---- Introduce CFG_USING_CLANG, which is distinguished from CFG_ENABLE_CLANG because the former represents "we think we're using clang, choose appropriate warning-control options" while the latter represents "we asked configure (or the host required) that we attempt to use clang, so check that we have an appropriate version of clang." The main reason I added this is that I wanted to allow the user to choose clang via setting the `CC` environment variable, but I did not want that method of selection to get confused with the user passing the `--enable-clang` option. ---- A digression: The `configure` script does not infer the compiler setting if `CC` is set; but if `--enable-clang` was passed, then it *does* still attempt to validate that the clang version is compatible. Supporting this required revising `CLANG_VERSION` check to be robust in face of user-provided `CC` value. In particular, on Travis, the `CC` is set to `gcc` and so the natural thing to do is to attempt to use `gcc` as the compiler, but Travis is also passing `--enable-clang` to configure. So, what is the right answer in the face of these contradictory requests? One approach would be to have `--enable-clang` supersede the setting for `CC` (and instead just call whatever we inferred for `CFG_CLANG`). That sounds maximally inflexible to me (pnkfelix): a developer requesting a `CC` value probably wants it respected, and should be able to set it to something else; it is harder for that developer to hack our configure script to change its inferred path to clang. A second approach would be to blindly use the `CC` value but keep going through the clang version check when `--enable-clang` is turned on. But on Travis (a Linux host), the `gcc` invocation won't print a clang version, so we would not get past the CLANG_VERSION check in that context. A third approach would be to never run the CLANG_VERSION check if `CC` is explicitly set. That is not a terrible idea; but if the user uses `CC` to pass in a path to some other version of clang that they want to test, probably should still send that through the `CLANG_VERSION` check. So in the end I (pnkfelix) took a fourth approach: do the CLANG_VERSION check if `CC` is unset *or* if `CC` is set to a string ending with `clang`. This way setting `CC` to things like `path/to/clang` or `ccache clang` will still go through the CLANG_VERSION check, while setting `CC` to `gcc` or some unknown compiler will skip the CLANG_VERSION check (regardless of whether the user passed --enable-clang to `configure`). ---- Drive-by fixes: * The call that sets `CFG_CLANG_VERSION` was quoting `"$CFG_CC"` in its invocation, but that does not play nicely with someone who sets `$CFG_CC` to e.g. `ccache clang`, since you do not want to intepret that whole string as a command. (On the other hand, a path with spaces might need the quoted invocation. Not sure which one of these corner use-cases is more important to support.) * Fix chk_cc error message to point user at `gcc` not `cc`.
2014-04-28 16:57:26 +00:00
endef
$(foreach cvar,CC CXX CPP CFLAGS CXXFLAGS CPPFLAGS, \
Make configure respect (and save) values for `CC`, `CXX`, `CFLAGS`, etc. I mostly tried to remain backwards compatible with old invocations of the `configure` script; if you do not want to use `CC` et al., you should not have to; you can keep using `--enable-clang` and/or `--enable-ccache`. The overall intention is to capture the following precedences for guessing the C compiler: 1. Value of `CC` at make invocation time. 2. Value of `CC` at configure invocation time. 3. Compiler inferred at configure invocation time (`gcc` or `clang`). The strategy is to check (at `configure` time) if each of the environment variables is set, and if so, save its value in a corresponding `CFG_` variable (e.g. `CFG_CC`). Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we use the `CFG_CC` setting as `CC`. Also, I fold the potential user-provided `CFLAGS` and `CXXFLAGS` values into all of the per-platform `CFLAGS` and `CXXFLAGS` settings. (This was opposed to adding `$(CFLAGS)` in an ad-hoc manner to various parts of the mk files.) Fix #13805. ---- Note that if you try to set the compiler to clang via the `CC` and `CXX` environment variables, you will probably need to also set `CXXFLAGS` to `--enable-libcpp` so that LLVM will be configured properly. ---- Introduce CFG_USING_CLANG, which is distinguished from CFG_ENABLE_CLANG because the former represents "we think we're using clang, choose appropriate warning-control options" while the latter represents "we asked configure (or the host required) that we attempt to use clang, so check that we have an appropriate version of clang." The main reason I added this is that I wanted to allow the user to choose clang via setting the `CC` environment variable, but I did not want that method of selection to get confused with the user passing the `--enable-clang` option. ---- A digression: The `configure` script does not infer the compiler setting if `CC` is set; but if `--enable-clang` was passed, then it *does* still attempt to validate that the clang version is compatible. Supporting this required revising `CLANG_VERSION` check to be robust in face of user-provided `CC` value. In particular, on Travis, the `CC` is set to `gcc` and so the natural thing to do is to attempt to use `gcc` as the compiler, but Travis is also passing `--enable-clang` to configure. So, what is the right answer in the face of these contradictory requests? One approach would be to have `--enable-clang` supersede the setting for `CC` (and instead just call whatever we inferred for `CFG_CLANG`). That sounds maximally inflexible to me (pnkfelix): a developer requesting a `CC` value probably wants it respected, and should be able to set it to something else; it is harder for that developer to hack our configure script to change its inferred path to clang. A second approach would be to blindly use the `CC` value but keep going through the clang version check when `--enable-clang` is turned on. But on Travis (a Linux host), the `gcc` invocation won't print a clang version, so we would not get past the CLANG_VERSION check in that context. A third approach would be to never run the CLANG_VERSION check if `CC` is explicitly set. That is not a terrible idea; but if the user uses `CC` to pass in a path to some other version of clang that they want to test, probably should still send that through the `CLANG_VERSION` check. So in the end I (pnkfelix) took a fourth approach: do the CLANG_VERSION check if `CC` is unset *or* if `CC` is set to a string ending with `clang`. This way setting `CC` to things like `path/to/clang` or `ccache clang` will still go through the CLANG_VERSION check, while setting `CC` to `gcc` or some unknown compiler will skip the CLANG_VERSION check (regardless of whether the user passed --enable-clang to `configure`). ---- Drive-by fixes: * The call that sets `CFG_CLANG_VERSION` was quoting `"$CFG_CC"` in its invocation, but that does not play nicely with someone who sets `$CFG_CC` to e.g. `ccache clang`, since you do not want to intepret that whole string as a command. (On the other hand, a path with spaces might need the quoted invocation. Not sure which one of these corner use-cases is more important to support.) * Fix chk_cc error message to point user at `gcc` not `cc`.
2014-04-28 16:57:26 +00:00
$(eval $(call SET_FROM_CFG,$(cvar))))
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 22:03:29 +00:00
CFG_RLIB_GLOB=lib$(1)-*.rlib
2013-03-07 06:36:20 +00:00
include $(wildcard $(CFG_SRC_DIR)mk/cfg/*.mk)
define ADD_INSTALLED_OBJECTS
INSTALLED_OBJECTS_$(1) += $$(call CFG_STATIC_LIB_NAME_$(1),morestack) \
$$(call CFG_STATIC_LIB_NAME_$(1),compiler-rt)
endef
$(foreach target,$(CFG_TARGET), \
$(eval $(call ADD_INSTALLED_OBJECTS,$(target))))
define DEFINE_LINKER
ifndef LINK_$(1)
LINK_$(1) := $$(CC_$(1))
endif
endef
$(foreach target,$(CFG_TARGET), \
$(eval $(call DEFINE_LINKER,$(target))))
# 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))))
# Configure various macros to pass gcc or cl.exe style arguments
define CC_MACROS
CFG_CC_INCLUDE_$(1)=-I $$(1)
ifeq ($$(findstring msvc,$(1)),msvc)
CFG_CC_OUTPUT_$(1)=-Fo:$$(1)
CFG_CREATE_ARCHIVE_$(1)=$$(AR_$(1)) -OUT:$$(1)
else
CFG_CC_OUTPUT_$(1)=-o $$(1)
CFG_CREATE_ARCHIVE_$(1)=$$(AR_$(1)) crus $$(1)
endif
endef
$(foreach target,$(CFG_TARGET), \
$(eval $(call CC_MACROS,$(target))))
ifeq ($(CFG_CCACHE_CPP2),1)
CCACHE_CPP2=1
export CCACHE_CPP
endif
2013-03-01 11:02:29 +00:00
ifdef CFG_CCACHE_BASEDIR
CCACHE_BASEDIR=$(CFG_CCACHE_BASEDIR)
export CCACHE_BASEDIR
endif
FIND_COMPILER = $(word 1,$(1:ccache=))
2013-03-07 06:36:20 +00:00
define CFG_MAKE_TOOLCHAIN
2013-11-20 06:30:51 +00:00
# Prepend the tools with their prefix if cross compiling
ifneq ($(CFG_BUILD),$(1))
ifneq ($$(findstring msvc,$(1)),msvc)
2015-05-08 21:44:17 +00:00
CC_$(1)=$(CROSS_PREFIX_$(1))$(CC_$(1))
CXX_$(1)=$(CROSS_PREFIX_$(1))$(CXX_$(1))
CPP_$(1)=$(CROSS_PREFIX_$(1))$(CPP_$(1))
AR_$(1)=$(CROSS_PREFIX_$(1))$(AR_$(1))
LINK_$(1)=$(CROSS_PREFIX_$(1))$(LINK_$(1))
RUSTC_CROSS_FLAGS_$(1)=-C linker=$$(call FIND_COMPILER,$$(LINK_$(1))) \
-C ar=$$(call FIND_COMPILER,$$(AR_$(1))) $(RUSTC_CROSS_FLAGS_$(1))
RUSTC_FLAGS_$(1)=$$(RUSTC_CROSS_FLAGS_$(1)) $(RUSTC_FLAGS_$(1))
endif
2013-11-20 06:30:51 +00:00
endif
CFG_COMPILE_C_$(1) = $$(CC_$(1)) \
$$(CFG_GCCISH_CFLAGS) \
2013-02-27 05:53:35 +00:00
$$(CFG_GCCISH_CFLAGS_$(1)) \
-c $$(call CFG_CC_OUTPUT_$(1),$$(1)) $$(2)
2013-03-07 06:36:20 +00:00
CFG_LINK_C_$(1) = $$(CC_$(1)) \
$$(CFG_GCCISH_LINK_FLAGS) -o $$(1) \
$$(CFG_GCCISH_LINK_FLAGS_$(1)) \
$$(CFG_GCCISH_DEF_FLAG_$(1))$$(3) $$(2) \
2013-02-27 05:53:35 +00:00
$$(call CFG_INSTALL_NAME_$(1),$$(4))
2013-03-07 06:36:20 +00:00
CFG_COMPILE_CXX_$(1) = $$(CXX_$(1)) \
$$(CFG_GCCISH_CFLAGS) \
$$(CFG_GCCISH_CXXFLAGS) \
2013-02-27 05:53:35 +00:00
$$(CFG_GCCISH_CFLAGS_$(1)) \
$$(CFG_GCCISH_CXXFLAGS_$(1)) \
-c $$(call CFG_CC_OUTPUT_$(1),$$(1)) $$(2)
2013-03-07 06:36:20 +00:00
CFG_LINK_CXX_$(1) = $$(CXX_$(1)) \
$$(CFG_GCCISH_LINK_FLAGS) -o $$(1) \
$$(CFG_GCCISH_LINK_FLAGS_$(1)) \
$$(CFG_GCCISH_DEF_FLAG_$(1))$$(3) $$(2) \
2013-02-27 05:53:35 +00:00
$$(call CFG_INSTALL_NAME_$(1),$$(4))
ifeq ($$(findstring $(HOST_$(1)),arm aarch64 mips mipsel powerpc),)
2013-02-27 05:53:35 +00:00
2015-03-28 15:09:51 +00:00
# On Bitrig, we need the relocation model to be PIC for everything
2015-01-17 07:51:04 +00:00
ifeq (,$(filter $(OSTYPE_$(1)),bitrig))
LLVM_MC_RELOCATION_MODEL="pic"
else
LLVM_MC_RELOCATION_MODEL="default"
endif
2013-03-07 06:36:20 +00:00
# We're using llvm-mc as our assembler because it supports
# .cfi pseudo-ops on mac
CFG_ASSEMBLE_$(1)=$$(CPP_$(1)) -E $$(2) | \
2013-10-21 09:18:21 +00:00
$$(LLVM_MC_$$(CFG_BUILD)) \
-assemble \
2015-01-17 07:51:04 +00:00
-relocation-model=$$(LLVM_MC_RELOCATION_MODEL) \
-filetype=obj \
-triple=$(1) \
-o=$$(1)
2013-02-27 05:53:35 +00:00
else
# For the ARM, AARCH64, MIPS and POWER crosses, use the toolchain assembler
# FIXME: We should be able to use the LLVM assembler
CFG_ASSEMBLE_$(1)=$$(CC_$(1)) $$(CFG_GCCISH_CFLAGS_$(1)) \
$$(2) -c -o $$(1)
2013-02-27 05:53:35 +00:00
endif
endef
$(foreach target,$(CFG_TARGET), \
2013-03-07 06:36:20 +00:00
$(eval $(call CFG_MAKE_TOOLCHAIN,$(target))))
# These two environment variables are scraped by the `./configure` script and
# are necessary for `cl.exe` to find standard headers (the INCLUDE variable) and
# for `link.exe` to find standard libraries (the LIB variable).
ifdef CFG_MSVC_INCLUDE_PATH
export INCLUDE := $(CFG_MSVC_INCLUDE_PATH)
endif
ifdef CFG_MSVC_LIB_PATH
export LIB := $(CFG_MSVC_LIB_PATH)
endif
# Unfortunately `link.exe` is also a program in `/usr/bin` on MinGW installs,
# but it's not the one that we want. As a result we make sure that our detected
# `link.exe` shows up in PATH first.
ifdef CFG_MSVC_LINK
export PATH := $(CFG_MSVC_ROOT)/VC/bin/amd64:$(PATH)
endif
# There are more comments about this available in the target specification for
# Windows MSVC in the compiler, but the gist of it is that we use `llvm-ar.exe`
# instead of `lib.exe` for assembling archives, so we need to inject this custom
# dependency here.
define ADD_LLVM_AR_TO_MSVC_DEPS
ifeq ($$(findstring msvc,$(1)),msvc)
NATIVE_TOOL_DEPS_core_T_$(1) += llvm-ar.exe
INSTALLED_BINS_$(1) += llvm-ar.exe
endif
endef
$(foreach target,$(CFG_TARGET), \
$(eval $(call ADD_LLVM_AR_TO_MSVC_DEPS,$(target))))
# When working with MSVC on windows, each DLL needs to explicitly declare its
# interface to the outside world through some means. The options for doing so
# include:
#
# 1. A custom attribute on each function itself
# 2. A linker argument saying what to export
# 3. A file which lists all symbols that need to be exported
#
# The Rust compiler takes care (1) for us for all Rust code by annotating all
# public-facing functions with dllexport, but we have a few native dependencies
# which need to cross the DLL boundary. The most important of these dependencies
# is LLVM which is linked into `rustc_llvm.dll` but primarily used from
# `rustc_trans.dll`. This means that many of LLVM's C API functions need to be
# exposed from `rustc_llvm.dll` to be forwarded over the boundary.
#
# Unfortunately, at this time, LLVM does not handle this sort of exportation on
# Windows for us, so we're forced to do it ourselves if we want it (which seems
# like the path of least resistance right now). To do this we generate a `.DEF`
# file [1] which we then custom-pass to the linker when building the rustc_llvm
# crate. This DEF file list all symbols that are exported from
# `src/librustc_llvm/lib.rs` and is generated by a small python script.
#
# Fun times!
#
# [1]: https://msdn.microsoft.com/en-us/library/28d6s79h.aspx
define ADD_RUSTC_LLVM_DEF_TO_MSVC
ifeq ($$(findstring msvc,$(1)),msvc)
RUSTFLAGS_rustc_llvm_T_$(1) += -C link-args="-DEF:$(1)/rt/rustc_llvm.def"
CUSTOM_DEPS_rustc_llvm_T_$(1) += $(1)/rt/rustc_llvm.def
$(1)/rt/rustc_llvm.def: $$(S)src/etc/mklldef.py $$(S)src/librustc_llvm/lib.rs
$$(CFG_PYTHON) $$^ $$@ rustc_llvm-$$(CFG_FILENAME_EXTRA)
endif
endef
$(foreach target,$(CFG_TARGET), \
$(eval $(call ADD_RUSTC_LLVM_DEF_TO_MSVC,$(target))))