2015-04-08 15:17:46 -05:00
#!/bin/sh
2011-03-16 11:17:32 -05:00
2016-01-26 08:15:10 -06:00
# /bin/sh on Solaris is not a POSIX compatible shell, but /usr/bin/bash is.
2016-01-21 10:30:22 -06:00
if [ `uname -s` = 'SunOS' -a "${POSIX_SHELL}" != "true" ]; then
POSIX_SHELL="true"
export POSIX_SHELL
2016-01-26 08:15:10 -06:00
exec /usr/bin/env bash $0 "$@"
2016-01-21 10:30:22 -06:00
fi
2016-01-26 08:15:10 -06:00
unset POSIX_SHELL # clear it so if we invoke other scripts, they run as bash as well
2016-01-21 10:30:22 -06:00
2011-03-18 01:51:45 -05:00
msg() {
2015-05-21 23:25:01 -05:00
echo "configure: $*"
2011-03-18 01:51:45 -05:00
}
2011-03-16 19:36:49 -05:00
2011-03-29 23:45:09 -05:00
step_msg() {
msg
msg "$1"
msg
}
2011-09-23 12:50:06 -05:00
warn() {
echo "configure: WARNING: $1"
}
2011-03-18 01:51:45 -05:00
err() {
echo "configure: error: $1"
exit 1
}
2015-04-27 02:58:31 -05:00
run() {
msg "$@"
"$@"
}
2012-01-05 20:59:54 -06:00
need_ok() {
if [ $? -ne 0 ]
then
2014-03-01 23:39:05 -06:00
err "$1"
2012-01-05 20:59:54 -06:00
fi
}
2011-03-19 20:31:59 -05:00
need_cmd() {
2014-03-28 23:16:41 -05:00
if command -v $1 >/dev/null 2>&1
2015-05-21 23:20:04 -05:00
then msg "found program '$1'"
else err "program '$1' is missing, please install it"
2011-03-19 20:31:59 -05:00
fi
}
2011-03-18 01:51:45 -05:00
make_dir() {
if [ ! -d $1 ]
then
2015-04-27 02:58:31 -05:00
run mkdir -p $1
2011-03-18 01:51:45 -05:00
fi
}
2012-02-28 14:05:05 -06:00
copy_if_changed() {
if cmp -s $1 $2
then
msg "leaving $2 unchanged"
else
2015-04-27 02:58:31 -05:00
run cp -f $1 $2
2012-02-28 20:41:54 -06:00
chmod u-w $2 # make copied artifact read-only
2012-02-28 14:05:05 -06:00
fi
}
move_if_changed() {
if cmp -s $1 $2
then
msg "leaving $2 unchanged"
else
2015-04-27 02:58:31 -05:00
run mv -f $1 $2
2012-02-28 20:41:54 -06:00
chmod u-w $2 # make moved artifact read-only
2012-02-28 14:05:05 -06:00
fi
2011-03-18 01:51:45 -05:00
}
2011-03-16 11:17:32 -05:00
2011-03-16 19:36:49 -05:00
putvar() {
local T
eval T=\$$1
2011-03-19 20:32:19 -05:00
eval TLEN=\${#$1}
if [ $TLEN -gt 35 ]
then
printf "configure: %-20s := %.35s ...\n" $1 "$T"
else
2012-04-10 05:25:59 -05:00
printf "configure: %-20s := %s %s\n" $1 "$T" "$2"
2011-03-19 20:32:19 -05:00
fi
2012-02-28 14:05:05 -06:00
printf "%-20s := %s\n" $1 "$T" >>config.tmp
2011-03-16 19:36:49 -05:00
}
2014-11-05 17:33:18 -06:00
putpathvar() {
local T
eval T=\$$1
eval TLEN=\${#$1}
if [ $TLEN -gt 35 ]
then
printf "configure: %-20s := %.35s ...\n" $1 "$T"
else
printf "configure: %-20s := %s %s\n" $1 "$T" "$2"
fi
2014-11-07 07:17:11 -06:00
if [ -z "$T" ]
then
printf "%-20s := \n" $1 >>config.tmp
else
printf "%-20s := \"%s\"\n" $1 "$T" >>config.tmp
fi
2014-11-05 17:33:18 -06:00
}
2011-03-16 19:36:49 -05:00
probe() {
local V=$1
2012-01-19 15:08:01 -06:00
shift
local P
2011-03-16 19:36:49 -05:00
local T
2012-01-19 15:08:01 -06:00
for P
do
2014-03-28 23:16:41 -05:00
T=$(command -v $P 2>&1)
2012-01-19 15:08:01 -06:00
if [ $? -eq 0 ]
then
2015-05-08 05:35:40 -05:00
VER0=$($P --version 2>/dev/null \
| grep -o '[vV]\?[0-9][0-9.][a-z0-9.-]*' | head -1 )
2012-04-10 05:25:59 -05:00
if [ $? -eq 0 -a "x${VER0}" != "x" ]
then
VER="($VER0)"
else
VER=""
fi
2012-01-19 15:08:01 -06:00
break
else
2012-04-10 05:25:59 -05:00
VER=""
2012-01-19 15:08:01 -06:00
T=""
fi
done
2011-03-16 19:36:49 -05:00
eval $V=\$T
2014-11-05 17:33:18 -06:00
putpathvar $V "$VER"
2011-03-16 19:36:49 -05:00
}
2011-03-18 01:51:45 -05:00
probe_need() {
2012-01-19 15:08:01 -06:00
probe $*
2016-06-03 06:53:46 -05:00
local V=$1
shift
2011-03-18 01:51:45 -05:00
eval VV=\$$V
if [ -z "$VV" ]
then
2016-06-03 06:53:46 -05:00
err "$V needed, but unable to find any of: $*"
2011-03-18 01:51:45 -05:00
fi
}
2012-11-30 22:20:18 -06:00
validate_opt () {
for arg in $CFG_CONFIGURE_ARGS
do
isArgValid=0
for option in $BOOL_OPTIONS
do
if test --disable-$option = $arg
then
isArgValid=1
fi
if test --enable-$option = $arg
then
isArgValid=1
fi
done
for option in $VAL_OPTIONS
do
if echo "$arg" | grep -q -- "--$option="
then
isArgValid=1
fi
done
2013-03-22 20:21:43 -05:00
if [ "$arg" = "--help" ]
2012-11-30 22:20:18 -06:00
then
2013-06-06 07:07:31 -05:00
echo
2013-03-22 20:21:43 -05:00
echo "No more help available for Configure options,"
echo "check the Wiki or join our IRC channel"
break
else
if test $isArgValid -eq 0
then
err "Option '$arg' is not recognized"
fi
2012-11-30 22:20:18 -06:00
fi
done
}
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
# `valopt OPTION_NAME DEFAULT DOC` extracts a string-valued option
# from command line, using provided default value for the option if
# not present, and saves it to the generated config.mk.
#
# `valopt_nosave` is much the same, except that it does not save the
# result to config.mk (instead the script should use `putvar` itself
# later on to save it). `valopt_core` is the core upon which the
# other two are built.
2012-11-30 22:20:18 -06:00
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
valopt_core() {
VAL_OPTIONS="$VAL_OPTIONS $2"
local SAVE=$1
local OP=$2
local DEFAULT=$3
shift
2011-11-02 17:58:21 -05:00
shift
shift
local DOC="$*"
if [ $HELP -eq 0 ]
then
2011-12-13 18:46:08 -06:00
local UOP=$(echo $OP | tr '[:lower:]' '[:upper:]' | tr '\-' '\_')
2011-11-02 18:03:34 -05:00
local V="CFG_${UOP}"
2015-04-14 02:43:59 -05:00
local V_PROVIDED="${V}_PROVIDED"
2011-11-02 18:03:34 -05:00
eval $V="$DEFAULT"
2011-11-02 17:58:21 -05:00
for arg in $CFG_CONFIGURE_ARGS
do
if echo "$arg" | grep -q -- "--$OP="
then
val=$(echo "$arg" | cut -f2 -d=)
eval $V=$val
2015-04-14 02:43:59 -05:00
eval $V_PROVIDED=1
2011-11-02 17:58:21 -05:00
fi
done
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
if [ "$SAVE" = "save" ]
then
putvar $V
fi
2011-11-02 17:58:21 -05:00
else
2011-11-02 18:03:34 -05:00
if [ -z "$DEFAULT" ]
then
DEFAULT="<none>"
fi
OP="${OP}=[${DEFAULT}]"
printf " --%-30s %s\n" "$OP" "$DOC"
2011-11-02 17:58:21 -05:00
fi
}
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
valopt_nosave() {
valopt_core nosave "$@"
}
valopt() {
valopt_core save "$@"
}
2012-11-30 22:20:18 -06:00
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
# `opt OPTION_NAME DEFAULT DOC` extracts a boolean-valued option from
# command line, using the provided default value (0/1) for the option
# if not present, and saves it to the generated config.mk.
#
# `opt_nosave` is much the same, except that it does not save the
# result to config.mk (instead the script should use `putvar` itself
# later on to save it). `opt_core` is the core upon which the other
# two are built.
opt_core() {
BOOL_OPTIONS="$BOOL_OPTIONS $2"
local SAVE=$1
local OP=$2
local DEFAULT=$3
shift
2011-03-29 23:45:09 -05:00
shift
shift
local DOC="$*"
local FLAG=""
if [ $DEFAULT -eq 0 ]
then
FLAG="enable"
2015-04-14 02:43:59 -05:00
DEFAULT_FLAG="disable"
2011-03-29 23:45:09 -05:00
else
FLAG="disable"
2015-04-14 02:43:59 -05:00
DEFAULT_FLAG="enable"
2011-03-29 23:45:09 -05:00
DOC="don't $DOC"
fi
if [ $HELP -eq 0 ]
then
for arg in $CFG_CONFIGURE_ARGS
do
if [ "$arg" = "--${FLAG}-${OP}" ]
then
2011-06-27 13:53:04 -05:00
OP=$(echo $OP | tr 'a-z-' 'A-Z_')
2011-03-29 23:45:09 -05:00
FLAG=$(echo $FLAG | tr 'a-z' 'A-Z')
local V="CFG_${FLAG}_${OP}"
2015-04-14 02:43:59 -05:00
local V_PROVIDED="CFG_${FLAG}_${OP}_PROVIDED"
2011-03-29 23:45:09 -05:00
eval $V=1
2015-04-14 02:43:59 -05:00
eval $V_PROVIDED=1
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
if [ "$SAVE" = "save" ]
then
putvar $V
fi
2015-04-14 02:43:59 -05:00
elif [ "$arg" = "--${DEFAULT_FLAG}-${OP}" ]
then
OP=$(echo $OP | tr 'a-z-' 'A-Z_')
DEFAULT_FLAG=$(echo $DEFAULT_FLAG | tr 'a-z' 'A-Z')
local V_PROVIDED="CFG_${DEFAULT_FLAG}_${OP}_PROVIDED"
eval $V_PROVIDED=1
2011-03-29 23:45:09 -05:00
fi
done
else
2015-07-26 16:18:30 -05:00
if [ -n "$META" ]
2011-03-29 23:45:09 -05:00
then
OP="$OP=<$META>"
fi
printf " --%-30s %s\n" "$FLAG-$OP" "$DOC"
fi
}
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
opt_nosave() {
opt_core nosave "$@"
}
opt() {
opt_core save "$@"
}
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 11:57:26 -05:00
envopt() {
local NAME=$1
local V="CFG_${NAME}"
eval VV=\$$V
# If configure didn't set a value already, then check environment.
#
# (It is recommended that the configure script always check the
# environment before setting any values to envopt variables; see
# e.g. how CFG_CC is handled, where it first checks `-z "$CC"`,
# and issues msg if it ends up employing that provided value.)
if [ -z "$VV" ]
then
eval $V=\$$NAME
eval VV=\$$V
fi
# If script or environment provided a value, save it.
2015-07-26 16:18:30 -05:00
if [ -n "$VV" ]
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 11:57:26 -05:00
then
putvar $V
fi
}
2015-07-20 03:07:53 -05:00
enable_if_not_disabled() {
local OP=$1
local UOP=$(echo $OP | tr '[:lower:]' '[:upper:]' | tr '\-' '\_')
local ENAB_V="CFG_ENABLE_$UOP"
local EXPLICITLY_DISABLED="CFG_DISABLE_${UOP}_PROVIDED"
eval VV=\$$EXPLICITLY_DISABLED
if [ -z "$VV" ]; then
eval $ENAB_V=1
fi
}
2014-07-23 13:56:36 -05:00
to_gnu_triple() {
case $1 in
i686-pc-windows-gnu) echo i686-w64-mingw32 ;;
x86_64-pc-windows-gnu) echo x86_64-w64-mingw32 ;;
*) echo $1 ;;
esac
}
2015-04-22 16:52:35 -05:00
# Prints the absolute path of a directory to stdout
abs_path() {
local _path="$1"
# Unset CDPATH because it causes havok: it makes the destination unpredictable
# and triggers 'cd' to print the path to stdout. Route `cd`'s output to /dev/null
# for good measure.
(unset CDPATH && cd "$_path" > /dev/null && pwd)
}
2016-09-01 08:19:35 -05:00
HELP=0
for arg; do
case "$arg" in
--help) HELP=1;;
esac
done
2011-03-19 20:31:59 -05:00
msg "looking for configure programs"
2012-02-28 14:05:05 -06:00
need_cmd cmp
2011-03-19 20:31:59 -05:00
need_cmd mkdir
need_cmd printf
2011-03-22 01:06:42 -05:00
need_cmd cut
2012-10-18 15:05:02 -05:00
need_cmd head
2011-03-22 01:06:42 -05:00
need_cmd grep
need_cmd xargs
need_cmd cp
need_cmd find
2011-03-23 15:26:17 -05:00
need_cmd uname
need_cmd date
2011-03-23 18:30:26 -05:00
need_cmd tr
2011-05-04 20:28:30 -05:00
need_cmd sed
2013-04-11 00:49:43 -05:00
need_cmd file
2015-01-22 21:44:43 -06:00
need_cmd make
2011-11-03 16:13:22 -05:00
2011-03-23 15:26:17 -05:00
msg "inspecting environment"
CFG_OSTYPE=$(uname -s)
CFG_CPUTYPE=$(uname -m)
2011-09-21 13:24:59 -05:00
2011-05-08 22:45:29 -05:00
if [ $CFG_OSTYPE = Darwin -a $CFG_CPUTYPE = i386 ]
then
# Darwin's `uname -s` lies and always returns i386. We have to use sysctl
# instead.
2012-02-28 20:42:28 -06:00
if sysctl hw.optional.x86_64 | grep -q ': 1'
2011-05-08 22:45:29 -05:00
then
CFG_CPUTYPE=x86_64
fi
fi
2011-03-23 15:26:17 -05:00
2011-09-21 13:24:59 -05:00
# The goal here is to come up with the same triple as LLVM would,
# at least for the subset of platforms we're willing to target.
case $CFG_OSTYPE in
Linux)
CFG_OSTYPE=unknown-linux-gnu
;;
FreeBSD)
CFG_OSTYPE=unknown-freebsd
;;
2014-07-29 09:44:39 -05:00
DragonFly)
CFG_OSTYPE=unknown-dragonfly
;;
2015-01-17 01:51:04 -06:00
Bitrig)
CFG_OSTYPE=unknown-bitrig
;;
2015-01-29 01:19:28 -06:00
OpenBSD)
2015-01-17 01:51:04 -06:00
CFG_OSTYPE=unknown-openbsd
2015-01-29 01:19:28 -06:00
;;
2015-06-30 22:37:11 -05:00
NetBSD)
CFG_OSTYPE=unknown-netbsd
;;
2011-09-21 13:24:59 -05:00
Darwin)
CFG_OSTYPE=apple-darwin
;;
2016-01-21 10:30:22 -06:00
SunOS)
CFG_OSTYPE=sun-solaris
CFG_CPUTYPE=$(isainfo -n)
;;
2016-09-24 23:49:11 -05:00
Haiku)
CFG_OSTYPE=unknown-haiku
;;
2014-08-22 11:45:15 -05:00
MINGW*)
# msys' `uname` does not print gcc configuration, but prints msys
# configuration. so we cannot believe `uname -m`:
# msys1 is always i686 and msys2 is always x86_64.
# instead, msys defines $MSYSTEM which is MINGW32 on i686 and
# MINGW64 on x86_64.
CFG_CPUTYPE=i686
2014-07-23 13:56:36 -05:00
CFG_OSTYPE=pc-windows-gnu
2014-08-22 11:45:15 -05:00
if [ "$MSYSTEM" = MINGW64 ]
then
CFG_CPUTYPE=x86_64
fi
2014-03-29 14:34:26 -05:00
;;
2014-07-23 13:56:36 -05:00
MSYS*)
CFG_OSTYPE=pc-windows-gnu
;;
2015-03-28 10:09:51 -05:00
# Thad's Cygwin identifiers below
2013-03-22 20:21:43 -05:00
# Vista 32 bit
CYGWIN_NT-6.0)
2014-07-23 13:56:36 -05:00
CFG_OSTYPE=pc-windows-gnu
2013-03-22 20:21:43 -05:00
CFG_CPUTYPE=i686
;;
# Vista 64 bit
CYGWIN_NT-6.0-WOW64)
2014-07-23 13:56:36 -05:00
CFG_OSTYPE=pc-windows-gnu
2013-03-22 20:21:43 -05:00
CFG_CPUTYPE=x86_64
;;
# Win 7 32 bit
CYGWIN_NT-6.1)
2014-07-23 13:56:36 -05:00
CFG_OSTYPE=pc-windows-gnu
2013-03-22 20:21:43 -05:00
CFG_CPUTYPE=i686
;;
2011-09-21 13:24:59 -05:00
2013-03-22 20:21:43 -05:00
# Win 7 64 bit
CYGWIN_NT-6.1-WOW64)
2014-07-23 13:56:36 -05:00
CFG_OSTYPE=pc-windows-gnu
2013-03-22 20:21:43 -05:00
CFG_CPUTYPE=x86_64
;;
2015-03-07 02:44:02 -06:00
# Win 8 # uname -s on 64-bit cygwin does not contain WOW64, so simply use uname -m to detect arch (works in my install)
CYGWIN_NT-6.3)
CFG_OSTYPE=pc-windows-gnu
;;
2013-03-22 20:21:43 -05:00
# We do not detect other OS such as XP/2003 using 64 bit using uname.
# If we want to in the future, we will need to use Cygwin - Chuck's csih helper in /usr/lib/csih/winProductName.exe or alternative.
2011-09-21 13:24:59 -05:00
*)
err "unknown OS type: $CFG_OSTYPE"
;;
esac
case $CFG_CPUTYPE in
i386 | i486 | i686 | i786 | x86)
2011-11-03 15:49:00 -05:00
CFG_CPUTYPE=i686
2011-09-21 13:24:59 -05:00
;;
xscale | arm)
CFG_CPUTYPE=arm
;;
2016-10-30 03:27:58 -05:00
armv6l)
CFG_CPUTYPE=arm
CFG_OSTYPE="${CFG_OSTYPE}eabihf"
;;
2014-05-28 01:42:35 -05:00
armv7l)
2016-10-30 03:26:25 -05:00
CFG_CPUTYPE=armv7
2014-05-28 01:42:35 -05:00
CFG_OSTYPE="${CFG_OSTYPE}eabihf"
;;
2014-12-12 17:39:27 -06:00
aarch64)
CFG_CPUTYPE=aarch64
;;
2015-12-28 15:09:06 -06:00
powerpc | ppc)
2015-01-09 21:49:54 -06:00
CFG_CPUTYPE=powerpc
;;
2015-12-28 15:09:06 -06:00
powerpc64 | ppc64)
CFG_CPUTYPE=powerpc64
;;
powerpc64le | ppc64le)
CFG_CPUTYPE=powerpc64le
;;
2016-09-09 16:00:23 -05:00
s390x)
CFG_CPUTYPE=s390x
;;
2011-12-30 02:18:55 -06:00
x86_64 | x86-64 | x64 | amd64)
2011-11-30 17:44:35 -06:00
CFG_CPUTYPE=x86_64
2011-09-21 13:24:59 -05:00
;;
2016-12-28 06:56:29 -06:00
mips | mips64)
if [ "$CFG_CPUTYPE" = "mips64" ]; then
CFG_OSTYPE="${CFG_OSTYPE}abi64"
fi
ENDIAN=$(printf '\1' | od -dAn)
if [ "$ENDIAN" -eq 1 ]; then
CFG_CPUTYPE="${CFG_CPUTYPE}el"
elif [ "$ENDIAN" -ne 256 ]; then
err "unknown endianness: $ENDIAN (expecting 1 for little or 256 for big)"
fi
;;
2016-09-24 23:49:11 -05:00
BePC)
CFG_CPUTYPE=i686
;;
2011-09-21 13:24:59 -05:00
*)
err "unknown CPU type: $CFG_CPUTYPE"
esac
2012-10-16 17:12:07 -05:00
# Detect 64 bit linux systems with 32 bit userland and force 32 bit compilation
if [ $CFG_OSTYPE = unknown-linux-gnu -a $CFG_CPUTYPE = x86_64 ]
then
2015-03-23 16:27:09 -05:00
# $SHELL does not exist in standard 'sh', so probably only exists
# if configure is running in an interactive bash shell. /usr/bin/env
# exists *everywhere*.
BIN_TO_PROBE="$SHELL"
2015-12-06 21:19:03 -06:00
if [ ! -r "$BIN_TO_PROBE" ]; then
if [ -r "/usr/bin/env" ]; then
BIN_TO_PROBE="/usr/bin/env"
else
warn "Cannot check if the userland is i686 or x86_64"
fi
fi
file -L "$BIN_TO_PROBE" | grep -q "x86[_-]64"
if [ $? != 0 ]; then
msg "i686 userland on x86_64 Linux kernel"
CFG_CPUTYPE=i686
2012-10-16 17:12:07 -05:00
fi
fi
2013-10-21 04:18:21 -05:00
DEFAULT_BUILD="${CFG_CPUTYPE}-${CFG_OSTYPE}"
2011-09-21 13:24:59 -05:00
2015-04-22 16:52:35 -05:00
CFG_SRC_DIR="$(abs_path $(dirname $0))/"
2015-06-12 12:40:07 -05:00
CFG_SRC_DIR_RELATIVE="$(dirname $0)/"
2012-04-30 17:40:04 -05:00
CFG_BUILD_DIR="$(pwd)/"
2014-03-01 23:39:05 -06:00
CFG_SELF="$0"
2011-03-25 12:29:45 -05:00
CFG_CONFIGURE_ARGS="$@"
2015-11-16 05:06:46 -06:00
2016-01-17 13:06:39 -06:00
case "${CFG_SRC_DIR}" in
2015-11-16 05:06:46 -06:00
*\ * )
err "The path to the rust source directory contains spaces, which is not supported"
;;
*)
;;
esac
2011-03-29 23:45:09 -05:00
OPTIONS=""
2016-09-01 08:19:35 -05:00
if [ "$HELP" -eq 1 ]
2011-03-29 23:45:09 -05:00
then
2013-06-06 07:07:31 -05:00
echo
2011-03-29 23:45:09 -05:00
echo "Usage: $CFG_SELF [options]"
2013-06-06 07:07:31 -05:00
echo
2011-03-29 23:45:09 -05:00
echo "Options:"
2013-06-06 07:07:31 -05:00
echo
2011-03-29 23:45:09 -05:00
else
2012-02-28 14:05:05 -06:00
msg "recreating config.tmp"
echo '' >config.tmp
2011-03-29 23:45:09 -05:00
step_msg "processing $CFG_SELF args"
fi
2011-03-18 01:51:45 -05:00
2012-11-30 22:20:18 -06:00
BOOL_OPTIONS=""
VAL_OPTIONS=""
2015-04-28 09:24:44 -05:00
opt debug 0 "debug mode; disables optimization unless \`--enable-optimize\` given"
2012-10-15 15:30:06 -05:00
opt valgrind 0 "run tests with valgrind (memcheck by default)"
2012-03-02 16:07:43 -06:00
opt helgrind 0 "run tests with helgrind instead of memcheck"
2014-10-08 18:11:37 -05:00
opt valgrind-rpass 1 "run rpass-valgrind tests with valgrind"
2015-03-27 22:01:19 -05:00
opt docs 1 "build standard library documentation"
opt compiler-docs 0 "build compiler documentation"
2013-08-11 02:29:45 -05:00
opt optimize-tests 1 "build tests with optimizations"
2015-04-29 10:18:44 -05:00
opt debuginfo-tests 0 "build tests with debugger metadata"
2016-10-29 20:58:52 -05:00
opt quiet-tests 0 "enable quieter output when running tests"
2016-06-12 18:05:32 -05:00
opt libcpp 1 "build llvm with libc++ instead of libstdc++ when using clang"
2015-04-08 15:27:12 -05:00
opt llvm-assertions 0 "build LLVM with assertions"
2015-04-08 15:25:20 -05:00
opt debug-assertions 0 "build with debugging assertions"
2012-02-10 14:07:01 -06:00
opt fast-make 0 "use .gitmodules as timestamp for submodule deps"
2013-05-29 16:18:09 -05:00
opt ccache 0 "invoke gcc/clang via ccache to reuse object files between builds"
2016-12-12 13:36:52 -06:00
opt sccache 0 "invoke gcc/clang via sccache to reuse object files between builds"
2012-04-05 17:40:34 -05:00
opt local-rust 0 "use an installed rustc rather than downloading a snapshot"
2016-07-14 12:32:53 -05:00
opt local-rebuild 0 "assume local-rust matches the current version, for rebuilds; implies local-rust, and is implied if local-rust already matches the current version"
2014-04-16 12:45:04 -05:00
opt llvm-static-stdcpp 0 "statically link to libstdc++ for LLVM"
2016-11-17 01:28:14 -06:00
opt llvm-link-shared 0 "prefer shared linking to LLVM (llvm-config --link-shared)"
2015-12-12 11:01:52 -06:00
opt rpath 1 "build rpaths into rustc itself"
2015-09-28 17:01:48 -05:00
opt stage0-landing-pads 1 "enable landing pads during bootstrap with stage0"
2014-07-22 19:20:15 -05:00
# This is used by the automation to produce single-target nightlies
opt dist-host-only 0 "only install bins for the host architecture"
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
opt inject-std-version 1 "inject the current compiler version of libstd into programs"
2015-05-30 20:12:32 -05:00
opt llvm-version-check 1 "check if the LLVM version is supported, build anyway"
2016-11-16 14:31:19 -06:00
opt rustbuild 1 "use the rust and cargo based build system"
2016-03-09 21:11:02 -06:00
opt codegen-tests 1 "run the src/test/codegen tests"
2016-02-03 09:29:53 -06:00
opt option-checking 1 "complain about unrecognized options in this configure script"
2016-07-01 18:47:30 -05:00
opt ninja 0 "build LLVM using the Ninja generator (for MSVC, requires building in the correct environment)"
2016-11-01 15:46:38 -05:00
opt vendor 0 "enable usage of vendored Rust crates"
2013-10-21 04:18:21 -05:00
2015-04-08 16:21:36 -05:00
# Optimization and debugging options. These may be overridden by the release channel, etc.
opt_nosave optimize 1 "build optimized rust code"
opt_nosave optimize-cxx 1 "build optimized C++ code"
opt_nosave optimize-llvm 1 "build optimized LLVM"
opt_nosave llvm-assertions 0 "build LLVM with assertions"
opt_nosave debug-assertions 0 "build with debugging assertions"
2016-11-13 12:38:10 -06:00
opt_nosave llvm-release-debuginfo 0 "build LLVM with debugger metadata"
2015-04-08 16:21:36 -05:00
opt_nosave debuginfo 0 "build with debugger metadata"
2016-10-19 11:48:46 -05:00
opt_nosave debuginfo-lines 0 "build with line number debugger metadata"
2017-01-10 22:01:54 -06:00
opt_nosave debuginfo-only-std 0 "build only libstd with debugging information"
2015-04-08 17:12:08 -05:00
opt_nosave debug-jemalloc 0 "build jemalloc with --enable-debug --enable-fill"
2015-04-08 16:21:36 -05:00
2013-10-21 04:18:21 -05:00
valopt localstatedir "/var/lib" "local state directory"
valopt sysconfdir "/etc" "install system configuration files"
2013-10-21 23:35:45 -05:00
valopt datadir "${CFG_PREFIX}/share" "install data"
valopt infodir "${CFG_PREFIX}/share/info" "install additional info"
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
valopt llvm-root "" "set LLVM root"
2015-06-02 17:16:30 -05:00
valopt python "" "set path to python"
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
valopt jemalloc-root "" "set directory where libjemalloc_pic.a is located"
valopt build "${DEFAULT_BUILD}" "GNUs ./configure syntax LLVM build triple"
2016-01-14 18:19:41 -06:00
valopt android-cross-path "" "Android NDK standalone path (deprecated)"
2015-08-09 00:15:50 -05:00
valopt i686-linux-android-ndk "" "i686-linux-android NDK standalone path"
2015-07-20 18:39:47 -05:00
valopt arm-linux-androideabi-ndk "" "arm-linux-androideabi NDK standalone path"
2016-05-04 17:08:14 -05:00
valopt armv7-linux-androideabi-ndk "" "armv7-linux-androideabi NDK standalone path"
2015-07-20 18:39:47 -05:00
valopt aarch64-linux-android-ndk "" "aarch64-linux-android NDK standalone path"
2015-12-15 15:34:06 -06:00
valopt nacl-cross-path "" "NaCl SDK path (Pepper Canary is recommended). Must be absolute!"
2016-10-05 13:00:55 -05:00
valopt musl-root "/usr/local" "MUSL root installation directory (deprecated)"
2016-11-16 14:31:19 -06:00
valopt musl-root-x86_64 "" "x86_64-unknown-linux-musl install directory"
valopt musl-root-i686 "" "i686-unknown-linux-musl install directory"
valopt musl-root-arm "" "arm-unknown-linux-musleabi install directory"
valopt musl-root-armhf "" "arm-unknown-linux-musleabihf install directory"
valopt musl-root-armv7 "" "armv7-unknown-linux-musleabihf install directory"
2015-12-28 18:11:42 -06:00
valopt extra-filename "" "Additional data that is hashed and passed to the -C extra-filename flag"
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
2016-05-30 15:29:29 -05:00
if [ -e ${CFG_SRC_DIR}.git ]
then
valopt release-channel "dev" "the name of the release channel to build"
else
# If we have no git directory then we are probably a tarball distribution
# and should default to stable channel - Issue 28322
probe CFG_GIT git
msg "git: no git directory. Changing default release channel to stable"
valopt release-channel "stable" "the name of the release channel to build"
fi
2015-08-10 18:09:21 -05:00
# Used on systems where "cc" and "ar" are unavailable
valopt default-linker "cc" "the default linker"
valopt default-ar "ar" "the default ar"
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
# Many of these are saved below during the "writing configuration" step
# (others are conditionally saved).
opt_nosave manage-submodules 1 "let the build manage the git submodules"
opt_nosave clang 0 "prefer clang to gcc for building the runtime"
2015-04-02 19:27:19 -05:00
opt_nosave jemalloc 1 "build liballoc with jemalloc"
2015-05-28 01:24:27 -05:00
opt elf-tls 1 "elf thread local storage on platforms where supported"
rustbuild: Compile rustc twice, not thrice
This commit switches the rustbuild build system to compiling the
compiler twice for a normal bootstrap rather than the historical three
times.
Rust is a bootstrapped language which means that a previous version of
the compiler is used to build the next version of the compiler. Over
time, however, we change many parts of compiler artifacts such as the
metadata format, symbol names, etc. These changes make artifacts from
one compiler incompatible from another compiler. Consequently if a
compiler wants to be able to use some artifacts then it itself must have
compiled the artifacts.
Historically the rustc build system has achieved this by compiling the
compiler three times:
* An older compiler (stage0) is downloaded to kick off the chain.
* This compiler now compiles a new compiler (stage1)
* The stage1 compiler then compiles another compiler (stage2)
* Finally, the stage2 compiler needs libraries to link against, so it
compiles all the libraries again.
This entire process amounts in compiling the compiler three times.
Additionally, this process always guarantees that the Rust source tree
can compile itself because the stage2 compiler (created by a freshly
created compiler) would successfully compile itself again. This
property, ensuring Rust can compile itself, is quite important!
In general, though, this third compilation is not required for general
purpose development on the compiler. The third compiler (stage2) can
reuse the libraries that were created during the second compile. In
other words, the second compilation can produce both a compiler and the
libraries that compiler will use. These artifacts *must* be compatible
due to the way plugins work today anyway, and they were created by the
same source code so they *should* be compatible as well.
So given all that, this commit switches the default build process to
only compile the compiler three times, avoiding this third compilation
by copying artifacts from the previous one. Along the way a new entry in
the Travis matrix was also added to ensure that our full bootstrap can
succeed. This entry does not run tests, though, as it should not be
necessary.
To restore the old behavior of a full bootstrap (three compiles) you can
either pass:
./configure --enable-full-bootstrap
or if you're using config.toml:
[build]
full-bootstrap = true
Overall this will hopefully be an easy 33% win in build times of the
compiler. If we do 33% less work we should be 33% faster! This in turn
should affect cycle times and such on Travis and AppVeyor positively as
well as making it easier to work on the compiler itself.
2016-12-25 17:20:33 -06:00
opt full-bootstrap 0 "build three compilers instead of two"
2014-01-07 10:51:15 -06:00
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
valopt_nosave prefix "/usr/local" "set installation prefix"
valopt_nosave local-rust-root "/usr/local" "set prefix for local rust binary"
valopt_nosave host "${CFG_BUILD}" "GNUs ./configure syntax LLVM host triples"
valopt_nosave target "${CFG_HOST}" "GNUs ./configure syntax LLVM target triples"
valopt_nosave mandir "${CFG_PREFIX}/share/man" "install man pages in PATH"
2016-09-15 12:26:16 -05:00
valopt_nosave docdir "${CFG_PREFIX}/share/doc/rust" "install documentation in PATH"
mk: Update how the build deals with version labels. #16677
Adds a new configure flag, --release-channel, which determines how the version
number should be augmented with a release label, as well as how the distribution
artifacts will be named. This is entirely for use by the build automation.
--release-channel can be either 'source', 'nightly', 'beta', or 'stable'.
Here's a summary of the affect of these values on version number and
artifact naming, respectively:
* source - '0.12.0-pre', 'rust-0.12.0-pre-...'
* nightly - '0.12.0-nightly', 'rust-nightly-...'
* beta - '0.12.0-beta', 'rust-beta-...'
* stable - '0.12.0', 'rust-0.12.0-...'
Per http://discuss.rust-lang.org/t/rfc-impending-changes-to-the-release-process/508/1
2014-09-15 15:40:30 -05:00
2015-11-01 01:26:12 -05:00
# On Windows this determines root of the subtree for target libraries.
# Host runtime libs always go to 'bin'.
valopt libdir "${CFG_PREFIX}/lib" "install libraries"
2014-11-23 08:36:36 -06:00
case "$CFG_LIBDIR" in
"$CFG_PREFIX"/*) CAT_INC=2;;
"$CFG_PREFIX"*) CAT_INC=1;;
*)
err "libdir must begin with the prefix. Use --prefix to set it accordingly.";;
esac
CFG_LIBDIR_RELATIVE=`echo ${CFG_LIBDIR} | cut -c$((${#CFG_PREFIX}+${CAT_INC}))-`
2014-01-07 10:51:15 -06:00
2011-11-02 18:25:22 -05:00
if [ $HELP -eq 1 ]
then
2013-06-06 07:07:31 -05:00
echo
2011-11-02 18:25:22 -05:00
exit 0
fi
2014-03-01 23:39:05 -06:00
# Validate Options
2016-01-21 11:18:43 -06:00
if [ -z "$CFG_DISABLE_OPTION_CHECKING" ]
then
step_msg "validating $CFG_SELF args"
validate_opt
fi
2011-03-16 19:36:49 -05:00
2015-04-09 13:51:46 -05:00
# Validate the release channel, and configure options
mk: Update how the build deals with version labels. #16677
Adds a new configure flag, --release-channel, which determines how the version
number should be augmented with a release label, as well as how the distribution
artifacts will be named. This is entirely for use by the build automation.
--release-channel can be either 'source', 'nightly', 'beta', or 'stable'.
Here's a summary of the affect of these values on version number and
artifact naming, respectively:
* source - '0.12.0-pre', 'rust-0.12.0-pre-...'
* nightly - '0.12.0-nightly', 'rust-nightly-...'
* beta - '0.12.0-beta', 'rust-beta-...'
* stable - '0.12.0', 'rust-0.12.0-...'
Per http://discuss.rust-lang.org/t/rfc-impending-changes-to-the-release-process/508/1
2014-09-15 15:40:30 -05:00
case "$CFG_RELEASE_CHANNEL" in
2015-04-09 13:51:46 -05:00
nightly )
msg "overriding settings for $CFG_RELEASE_CHANNEL"
CFG_ENABLE_LLVM_ASSERTIONS=1
2017-01-10 22:01:54 -06:00
# FIXME(stage0) re-enable this on the next stage0 now that #35566 is
# fixed
2016-10-23 12:25:01 -05:00
case "$CFG_BUILD" in
*-pc-windows-gnu)
;;
*)
2017-01-10 22:01:54 -06:00
CFG_ENABLE_DEBUGINFO_LINES=1
CFG_ENABLE_DEBUGINFO_ONLY_STD=1
2016-10-23 12:25:01 -05:00
;;
esac
2017-01-10 22:01:54 -06:00
mk: Update how the build deals with version labels. #16677
Adds a new configure flag, --release-channel, which determines how the version
number should be augmented with a release label, as well as how the distribution
artifacts will be named. This is entirely for use by the build automation.
--release-channel can be either 'source', 'nightly', 'beta', or 'stable'.
Here's a summary of the affect of these values on version number and
artifact naming, respectively:
* source - '0.12.0-pre', 'rust-0.12.0-pre-...'
* nightly - '0.12.0-nightly', 'rust-nightly-...'
* beta - '0.12.0-beta', 'rust-beta-...'
* stable - '0.12.0', 'rust-0.12.0-...'
Per http://discuss.rust-lang.org/t/rfc-impending-changes-to-the-release-process/508/1
2014-09-15 15:40:30 -05:00
;;
2016-10-19 11:48:46 -05:00
beta | stable)
msg "overriding settings for $CFG_RELEASE_CHANNEL"
2016-10-23 12:25:01 -05:00
case "$CFG_BUILD" in
*-pc-windows-gnu)
;;
*)
2017-01-10 22:01:54 -06:00
CFG_ENABLE_DEBUGINFO_LINES=1
CFG_ENABLE_DEBUGINFO_ONLY_STD=1
2016-10-23 12:25:01 -05:00
;;
esac
2016-10-19 11:48:46 -05:00
;;
dev)
2015-04-09 13:51:46 -05:00
;;
*)
2014-09-25 17:28:00 -05:00
err "release channel must be 'dev', 'nightly', 'beta' or 'stable'"
mk: Update how the build deals with version labels. #16677
Adds a new configure flag, --release-channel, which determines how the version
number should be augmented with a release label, as well as how the distribution
artifacts will be named. This is entirely for use by the build automation.
--release-channel can be either 'source', 'nightly', 'beta', or 'stable'.
Here's a summary of the affect of these values on version number and
artifact naming, respectively:
* source - '0.12.0-pre', 'rust-0.12.0-pre-...'
* nightly - '0.12.0-nightly', 'rust-nightly-...'
* beta - '0.12.0-beta', 'rust-beta-...'
* stable - '0.12.0', 'rust-0.12.0-...'
Per http://discuss.rust-lang.org/t/rfc-impending-changes-to-the-release-process/508/1
2014-09-15 15:40:30 -05:00
;;
esac
2015-04-08 16:21:36 -05:00
# Adjust perf and debug options for debug mode
if [ -n "$CFG_ENABLE_DEBUG" ]; then
msg "debug mode enabled, setting performance options"
2015-04-14 02:58:57 -05:00
if [ -z "$CFG_ENABLE_OPTIMIZE_PROVIDED" ]; then
msg "optimization not explicitly enabled, disabling optimization"
CFG_DISABLE_OPTIMIZE=1
CFG_DISABLE_OPTIMIZE_CXX=1
fi
2015-07-20 03:07:53 -05:00
# Set following variables to 1 unless setting already provided
enable_if_not_disabled debug-assertions
enable_if_not_disabled debug-jemalloc
enable_if_not_disabled debuginfo
enable_if_not_disabled llvm-assertions
2015-04-08 16:21:36 -05:00
fi
# OK, now write the debugging options
if [ -n "$CFG_DISABLE_OPTIMIZE" ]; then putvar CFG_DISABLE_OPTIMIZE; fi
if [ -n "$CFG_DISABLE_OPTIMIZE_CXX" ]; then putvar CFG_DISABLE_OPTIMIZE_CXX; fi
if [ -n "$CFG_DISABLE_OPTIMIZE_LLVM" ]; then putvar CFG_DISABLE_OPTIMIZE_LLVM; fi
if [ -n "$CFG_ENABLE_LLVM_ASSERTIONS" ]; then putvar CFG_ENABLE_LLVM_ASSERTIONS; fi
if [ -n "$CFG_ENABLE_DEBUG_ASSERTIONS" ]; then putvar CFG_ENABLE_DEBUG_ASSERTIONS; fi
2016-11-13 12:38:10 -06:00
if [ -n "$CFG_ENABLE_LLVM_RELEASE_DEBUGINFO" ]; then putvar CFG_ENABLE_LLVM_RELEASE_DEBUGINFO; fi
2015-04-08 16:21:36 -05:00
if [ -n "$CFG_ENABLE_DEBUGINFO" ]; then putvar CFG_ENABLE_DEBUGINFO; fi
2016-10-19 11:48:46 -05:00
if [ -n "$CFG_ENABLE_DEBUGINFO_LINES" ]; then putvar CFG_ENABLE_DEBUGINFO_LINES; fi
2017-01-10 22:01:54 -06:00
if [ -n "$CFG_ENABLE_DEBUGINFO_ONLY_STD" ]; then putvar CFG_ENABLE_DEBUGINFO_ONLY_STD; fi
2015-04-08 17:12:08 -05:00
if [ -n "$CFG_ENABLE_DEBUG_JEMALLOC" ]; then putvar CFG_ENABLE_DEBUG_JEMALLOC; fi
2015-04-08 16:21:36 -05:00
2011-03-29 23:45:09 -05:00
step_msg "looking for build programs"
2011-11-03 16:13:22 -05:00
2016-06-03 06:53:46 -05:00
probe_need CFG_CURL curl
2015-06-02 17:16:30 -05:00
if [ -z "$CFG_PYTHON_PROVIDED" ]; then
2016-02-13 14:19:44 -06:00
probe_need CFG_PYTHON python2.7 python2 python
2015-06-02 17:16:30 -05:00
fi
2012-06-25 19:18:09 -05:00
python_version=$($CFG_PYTHON -V 2>&1)
2016-02-13 14:19:44 -06:00
if [ $(echo $python_version | grep -c '^Python 2\.7') -ne 1 ]; then
err "Found $python_version, but Python 2.7 is required"
2012-06-25 19:18:09 -05:00
fi
2012-02-29 12:18:04 -06:00
# If we have no git directory then we are probably a tarball distribution
# and shouldn't attempt to load submodules
if [ ! -e ${CFG_SRC_DIR}.git ]
then
2012-02-29 13:48:29 -06:00
probe CFG_GIT git
2012-02-29 12:18:04 -06:00
msg "git: no git directory. disabling submodules"
CFG_DISABLE_MANAGE_SUBMODULES=1
else
2012-02-29 13:48:29 -06:00
probe_need CFG_GIT git
2012-02-29 12:18:04 -06:00
fi
2015-05-08 05:26:26 -05:00
# Use `md5sum` on GNU platforms, or `md5 -q` on BSD
probe CFG_MD5 md5
probe CFG_MD5SUM md5sum
if [ -n "$CFG_MD5" ]
then
2015-05-20 06:54:14 -05:00
CFG_HASH_COMMAND="$CFG_MD5 -q | cut -c 1-8"
2015-05-08 05:26:26 -05:00
elif [ -n "$CFG_MD5SUM" ]
then
2015-05-20 06:54:14 -05:00
CFG_HASH_COMMAND="$CFG_MD5SUM | cut -c 1-8"
2015-05-08 05:26:26 -05:00
else
err 'could not find one of: md5 md5sum'
fi
putvar CFG_HASH_COMMAND
2011-05-09 12:16:56 -05:00
probe CFG_CLANG clang++
2013-05-29 16:18:09 -05:00
probe CFG_CCACHE ccache
2011-05-08 23:10:04 -05:00
probe CFG_GCC gcc
2012-04-10 05:25:59 -05:00
probe CFG_LD ld
2011-03-16 19:36:49 -05:00
probe CFG_VALGRIND valgrind
2011-09-13 17:06:21 -05:00
probe CFG_PERF perf
2012-01-25 18:02:53 -06:00
probe CFG_ISCC iscc
2014-07-15 02:18:17 -05:00
probe CFG_ANTLR4 antlr4
probe CFG_GRUN grun
2015-01-20 20:46:44 -06:00
probe CFG_FLEX flex
probe CFG_BISON bison
2013-02-10 16:17:28 -06:00
probe CFG_GDB gdb
2014-04-24 04:35:48 -05:00
probe CFG_LLDB lldb
2016-07-01 18:47:30 -05:00
if [ -n "$CFG_ENABLE_NINJA" ]
then
probe CFG_NINJA ninja
if [ -z "$CFG_NINJA" ]
then
# On Debian and Fedora, the `ninja` binary is an IRC bot, so the build tool was
# renamed. Handle this case.
probe CFG_NINJA ninja-build
fi
fi
2016-06-01 19:41:27 -05:00
# For building LLVM
2016-12-02 08:43:03 -06:00
if [ -z "$CFG_LLVM_ROOT" ]
then
probe_need CFG_CMAKE cmake
fi
2016-06-01 19:41:27 -05:00
2015-04-03 08:05:54 -05:00
# On MacOS X, invoking `javac` pops up a dialog if the JDK is not
# installed. Since `javac` is only used if `antlr4` is available,
# probe for it only in this case.
2015-07-26 16:18:30 -05:00
if [ -n "$CFG_ANTLR4" ]
2015-04-03 08:05:54 -05:00
then
2016-07-23 06:51:54 -05:00
CFG_ANTLR4_JAR="\"$(find /usr/ -name antlr-complete.jar 2>/dev/null | head -n 1)\""
2016-11-21 16:10:51 -06:00
if [ "x" = "x$CFG_ANTLR4_JAR" ]
2016-07-23 06:51:54 -05:00
then
CFG_ANTLR4_JAR="\"$(find ~ -name antlr-complete.jar 2>/dev/null | head -n 1)\""
fi
putvar CFG_ANTLR4_JAR $CFG_ANTLR4_JAR
2015-04-03 08:05:54 -05:00
probe CFG_JAVAC javac
fi
2015-04-27 03:04:22 -05:00
# the valgrind rpass tests will fail if you don't have a valgrind, but they're
# only disabled if you opt out.
if [ -z "$CFG_VALGRIND" ]
then
2015-04-28 01:54:30 -05:00
# If the user has explicitly asked for valgrind tests, then fail
if [ -n "$CFG_ENABLE_VALGRIND" ] && [ -n "$CFG_ENABLE_VALGRIND_PROVIDED" ]
then
err "No valgrind present, but valgrind tests explicitly requested"
else
CFG_DISABLE_VALGRIND_RPASS=1
putvar CFG_DISABLE_VALGRIND_RPASS
fi
2015-04-27 03:04:22 -05:00
fi
2015-07-26 16:18:30 -05:00
if [ -n "$CFG_LLDB" ]
2014-04-24 04:35:48 -05:00
then
2014-10-02 04:35:24 -05:00
# Store LLDB's version
CFG_LLDB_VERSION=$($CFG_LLDB --version 2>/dev/null | head -1)
putvar CFG_LLDB_VERSION
2014-04-24 04:35:48 -05:00
# If CFG_LLDB_PYTHON_DIR is not already set from the outside and valid, try to read it from
# LLDB via the -P commandline options.
if [ -z "$CFG_LLDB_PYTHON_DIR" ] || [ ! -d "$CFG_LLDB_PYTHON_DIR" ]
then
CFG_LLDB_PYTHON_DIR=$($CFG_LLDB -P)
# If CFG_LLDB_PYTHON_DIR is not a valid directory, set it to something more readable
if [ ! -d "$CFG_LLDB_PYTHON_DIR" ]
then
CFG_LLDB_PYTHON_DIR="LLDB_PYTHON_DIRECTORY_NOT_FOUND"
fi
putvar CFG_LLDB_PYTHON_DIR
fi
fi
2016-04-19 11:44:19 -05:00
# LLDB tests on OSX require /usr/bin/python, not something like Homebrew's
# /usr/local/bin/python. We're loading a compiled module for LLDB tests which is
# only compatible with the system.
case $CFG_BUILD in
*-apple-darwin)
CFG_LLDB_PYTHON=/usr/bin/python
;;
*)
CFG_LLDB_PYTHON=$CFG_PYTHON
;;
esac
putvar CFG_LLDB_PYTHON
2016-12-22 16:00:21 -06:00
# Do some sanity checks if running on buildbot
# (these env vars are set by rust-buildbot)
if [ -n "$RUST_DIST_SERVER" -a -n "$ALLOW_NONZERO_RLIMIT_CORE" ]; then
# Frequently the llvm submodule directory is broken by the build
# being killed
llvm_lock="${CFG_SRC_DIR}/.git/modules/src/llvm/index.lock"
if [ -e "$llvm_lock" ]; then
step_msg "removing $llvm_lock"
rm -f "$llvm_lock"
fi
fi
2013-05-03 10:46:52 -05:00
step_msg "looking for target specific programs"
probe CFG_ADB adb
2013-11-20 21:29:40 -06:00
BIN_SUF=
2015-03-04 16:58:59 -06:00
if [ "$CFG_OSTYPE" = "pc-windows-gnu" ] || [ "$CFG_OSTYPE" = "pc-windows-msvc" ]
2013-11-20 21:29:40 -06:00
then
BIN_SUF=.exe
fi
2016-05-21 18:36:25 -05:00
# --enable-local-rebuild implies --enable-local-rust too
if [ -n "$CFG_ENABLE_LOCAL_REBUILD" ]
then
if [ -z "$CFG_ENABLE_LOCAL_RUST" ]
then
CFG_ENABLE_LOCAL_RUST=1
putvar CFG_ENABLE_LOCAL_RUST
fi
fi
2015-07-26 16:18:30 -05:00
if [ -n "$CFG_ENABLE_LOCAL_RUST" ]
2012-04-05 17:40:34 -05:00
then
2014-08-07 07:00:35 -05:00
system_rustc=$(which rustc)
if [ -f ${CFG_LOCAL_RUST_ROOT}/bin/rustc${BIN_SUF} ]
2012-04-19 17:46:09 -05:00
then
2014-08-07 07:00:35 -05:00
: # everything already configured
elif [ -n "$system_rustc" ]
then
# we assume that rustc is in a /bin directory
CFG_LOCAL_RUST_ROOT=${system_rustc%/bin/rustc}
2012-04-19 17:46:09 -05:00
else
2014-08-07 07:00:35 -05:00
err "no local rust to use"
2012-04-19 17:46:09 -05:00
fi
2014-08-07 07:00:35 -05:00
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
CMD="${CFG_LOCAL_RUST_ROOT}/bin/rustc${BIN_SUF}"
2016-09-03 07:06:38 -05:00
LRV=`LD_LIBRARY_PATH=${CFG_LOCAL_RUST_ROOT}/lib $CMD --version`
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
if [ $? -ne 0 ]
then
step_msg "failure while running $CMD --version"
exit 1
fi
2014-08-07 07:00:35 -05:00
step_msg "using rustc at: ${CFG_LOCAL_RUST_ROOT} with version: $LRV"
putvar CFG_LOCAL_RUST_ROOT
2012-04-05 17:40:34 -05:00
fi
2015-01-17 01:51:04 -06:00
# Force bitrig to build with clang; gcc doesn't like us there
if [ $CFG_OSTYPE = unknown-bitrig ]
then
2016-02-08 12:57:41 -06:00
step_msg "on Bitrig, forcing use of clang"
2015-01-17 01:51:04 -06:00
CFG_ENABLE_CLANG=1
fi
2015-09-10 01:50:12 -05:00
# default gcc version under OpenBSD maybe too old, try using egcc, which is a
# gcc version from ports
if [ $CFG_OSTYPE = unknown-openbsd ]
then
if [ $("$CFG_GCC" --version 2>&1 | grep -c ' 4\.[0-6]') -ne 0 ]; then
step_msg "older GCC found, try with egcc instead"
# probe again but using egcc
probe CFG_GCC egcc
# and use egcc/eg++ for CC/CXX too if it was found
# (but user setting has priority)
if [ -n "$CFG_GCC" ]; then
CC="${CC:-egcc}"
CXX="${CXX:-eg++}"
fi
2015-09-10 11:50:01 -05:00
fi
2016-01-17 13:06:39 -06:00
fi
2013-12-14 18:11:48 -06:00
# OS X 10.9, gcc is actually clang. This can cause some confusion in the build
# system, so if we find that gcc is clang, we should just use clang directly.
if [ $CFG_OSTYPE = apple-darwin -a -z "$CFG_ENABLE_CLANG" ]
then
CFG_OSX_GCC_VERSION=$("$CFG_GCC" --version 2>&1 | grep "Apple LLVM version")
if [ $? -eq 0 ]
then
2015-05-07 18:11:18 -05:00
step_msg "on OS X >=10.9, forcing use of clang"
2013-12-14 18:11:48 -06:00
CFG_ENABLE_CLANG=1
2014-01-07 10:45:41 -06:00
else
2014-04-14 12:27:16 -05:00
if [ $("$CFG_GCC" --version 2>&1 | grep -c ' 4\.[0-6]') -ne 0 ]; then
step_msg "older GCC found, using clang instead"
CFG_ENABLE_CLANG=1
else
# on OS X, with xcode 5 and newer, certain developers may have
# cc, gcc and g++ point to a mixture of clang and gcc
# if so, this will create very strange build errors
# this last stanza is to detect some such problems and save the future rust
# contributor some time solving that issue.
# this detection could be generalized to other OSes aside from OS X
# but the issue seems most likely to happen on OS X
chk_cc () {
$1 --version 2> /dev/null | grep -q $2
}
# check that gcc, cc and g++ all point to the same compiler.
# note that for xcode 5, g++ points to clang, not clang++
if !((chk_cc gcc clang && chk_cc g++ clang) ||
2014-09-15 16:08:04 -05:00
(chk_cc gcc gcc &&( chk_cc g++ g++ || chk g++ gcc))); then
2014-04-14 12:27:16 -05:00
err "the gcc and g++ in your path point to different compilers.
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 11:57:26 -05:00
Check which versions are in your path with gcc --version and g++ --version.
2014-04-14 12:27:16 -05:00
To resolve this problem, either fix your PATH or run configure with --enable-clang"
fi
2013-12-14 01:59:40 -06:00
2014-04-14 12:27:16 -05:00
fi
2013-12-14 18:11:48 -06:00
fi
fi
2015-06-10 13:49:07 -05:00
# If the clang isn't already enabled, check for GCC, and if it is missing, turn
# on clang as a backup.
if [ -z "$CFG_ENABLE_CLANG" ]
then
2015-06-24 14:48:08 -05:00
CFG_GCC_VERSION=$("$CFG_GCC" --version 2>&1)
2015-06-10 13:49:07 -05:00
if [ $? -ne 0 ]
then
step_msg "GCC not installed, will try using Clang"
CFG_ENABLE_CLANG=1
fi
fi
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
# Okay, at this point, we have made up our minds about whether we are
# going to force CFG_ENABLE_CLANG or not; save the setting if so.
2015-07-26 16:18:30 -05:00
if [ -n "$CFG_ENABLE_CLANG" ]
config.mk: Added variants of `valopt`/`opt` that do not automatically `putvar`.
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix #17887.
2014-10-09 09:26:46 -05:00
then
putvar CFG_ENABLE_CLANG
fi
2015-08-21 23:43:56 -05:00
if [ -z "$CFG_DISABLE_LIBCPP" -a -n "$CFG_ENABLE_CLANG" ]
then
CFG_USING_LIBCPP="1"
else
CFG_USING_LIBCPP="0"
fi
2015-04-02 19:27:19 -05:00
# Same with jemalloc. save the setting here.
2015-07-26 16:18:30 -05:00
if [ -n "$CFG_DISABLE_JEMALLOC" ]
2015-04-02 19:27:19 -05:00
then
putvar CFG_DISABLE_JEMALLOC
fi
2015-07-26 16:18:30 -05:00
if [ -n "$CFG_LLVM_ROOT" -a -z "$CFG_DISABLE_LLVM_VERSION_CHECK" -a -e "$CFG_LLVM_ROOT/bin/llvm-config" ]
2011-05-18 21:32:18 -05:00
then
2011-11-02 17:10:19 -05:00
step_msg "using custom LLVM at $CFG_LLVM_ROOT"
2011-11-02 16:07:32 -05:00
LLVM_CONFIG="$CFG_LLVM_ROOT/bin/llvm-config"
2011-11-02 17:10:19 -05:00
LLVM_VERSION=$($LLVM_CONFIG --version)
2011-11-02 16:07:32 -05:00
case $LLVM_VERSION in
2016-08-11 11:55:53 -05:00
(3.[7-9]*)
2013-12-13 10:33:50 -06:00
msg "found ok version of LLVM: $LLVM_VERSION"
;;
(*)
2016-06-05 17:25:11 -05:00
err "bad LLVM version: $LLVM_VERSION, need >=3.7"
2013-12-13 10:33:50 -06:00
;;
2011-11-02 16:07:32 -05:00
esac
2016-07-21 04:24:35 -05:00
2016-07-25 12:20:05 -05:00
if "$CFG_LLVM_ROOT/bin/llvm-mc" -help | grep -- "-relocation-model"; then
msg "found older llvm-mc"
2016-07-21 04:24:35 -05:00
CFG_LLVM_MC_HAS_RELOCATION_MODEL=1
putvar CFG_LLVM_MC_HAS_RELOCATION_MODEL
fi
2011-03-21 20:08:57 -05:00
fi
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 11:57:26 -05:00
# Even when the user overrides the choice of CC, still try to detect
# clang to disable some clang-specific warnings. We here draw a
# distinction between:
#
# CFG_ENABLE_CLANG : passed --enable-clang, or host "requires" clang,
# CFG_USING_CLANG : compiler (clang / gcc / $CC) looks like clang.
#
# This distinction is important because there are some safeguards we
# would prefer to skip when merely CFG_USING_CLANG is set; but when
# CFG_ENABLE_CLANG is set, that indicates that we are opting into
# running such safeguards.
2015-07-26 16:18:30 -05:00
if [ -n "$CC" ]
2011-05-18 23:41:40 -05:00
then
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 11:57:26 -05:00
msg "skipping compiler inference steps; using provided CC=$CC"
CFG_CC="$CC"
CFG_OSX_CC_VERSION=$("$CFG_CC" --version 2>&1 | grep "clang")
if [ $? -eq 0 ]
2011-11-03 14:01:31 -05:00
then
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 11:57:26 -05:00
step_msg "note, user-provided CC looks like clang; CC=$CC."
CFG_USING_CLANG=1
putvar CFG_USING_CLANG
2011-11-03 14:01:31 -05:00
fi
2011-08-05 10:57:39 -05:00
else
2015-07-26 16:18:30 -05:00
if [ -n "$CFG_ENABLE_CLANG" ]
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 11:57:26 -05:00
then
if [ -z "$CFG_CLANG" ]
then
err "clang requested but not found"
fi
CFG_CC="$CFG_CLANG"
CFG_USING_CLANG=1
putvar CFG_USING_CLANG
else
CFG_CC="gcc"
fi
fi
2015-07-26 16:18:30 -05:00
if [ -n "$CFG_ENABLE_CLANG" ]
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 11:57:26 -05:00
then
2015-05-23 14:57:50 -05:00
case "$CC" in
(''|*clang)
2015-07-13 01:33:36 -05:00
if [ -z "$CC" ]
then
CFG_CC="clang"
CFG_CXX="clang++"
fi
2015-05-23 14:57:50 -05:00
esac
2011-05-18 23:41:40 -05:00
fi
2011-09-23 12:50:06 -05:00
2015-07-26 16:18:30 -05:00
if [ -n "$CFG_ENABLE_CCACHE" ]
2013-05-29 16:18:09 -05:00
then
2015-07-13 19:29:01 -05:00
if [ -z "$CFG_CCACHE" ]
2013-05-29 16:18:09 -05:00
then
2015-07-13 19:29:01 -05:00
err "ccache requested but not found"
2013-05-29 16:18:09 -05:00
fi
2015-07-13 19:29:01 -05:00
CFG_CC="ccache $CFG_CC"
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 11:57:26 -05:00
fi
2013-05-29 16:18:09 -05:00
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 11:57:26 -05:00
if [ -z "$CC" -a -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
err "either clang or gcc is required"
2013-05-29 16:18:09 -05:00
fi
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 11:57:26 -05:00
# All safeguards based on $CFG_ENABLE_CLANG should occur before this
# point in the script; after this point, script logic should inspect
# $CFG_USING_CLANG rather than $CFG_ENABLE_CLANG.
2015-11-20 08:48:19 -06:00
# Set CFG_{CC,CXX,CPP,CFLAGS,CXXFLAGS,LDFLAGS}
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 11:57:26 -05:00
envopt CC
envopt CXX
envopt CPP
envopt CFLAGS
envopt CXXFLAGS
2015-11-20 08:48:19 -06:00
envopt LDFLAGS
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 11:57:26 -05:00
2015-09-18 09:30:45 -05:00
# stdc++ name in use
# used to manage non-standard name (on OpenBSD for example)
program_transform_name=$($CFG_CC -v 2>&1 | sed -n "s/.*--program-transform-name='\([^']*\)'.*/\1/p")
CFG_STDCPP_NAME=$(echo "stdc++" | sed "${program_transform_name}")
putvar CFG_STDCPP_NAME
2012-01-30 18:29:13 -06:00
# a little post-processing of various config values
CFG_PREFIX=${CFG_PREFIX%/}
2013-10-21 04:18:21 -05:00
CFG_MANDIR=${CFG_MANDIR%/}
2016-09-09 01:18:20 -05:00
CFG_DOCDIR=${CFG_DOCDIR%/}
2013-10-21 04:18:21 -05:00
CFG_HOST="$(echo $CFG_HOST | tr ',' ' ')"
CFG_TARGET="$(echo $CFG_TARGET | tr ',' ' ')"
2014-11-19 13:53:18 -06:00
CFG_SUPPORTED_TARGET=""
for target_file in ${CFG_SRC_DIR}mk/cfg/*.mk; do
CFG_SUPPORTED_TARGET="${CFG_SUPPORTED_TARGET} $(basename "$target_file" .mk)"
done
2011-12-02 18:04:17 -06:00
2015-06-21 22:53:34 -05:00
# copy build-triples to host-triples so that builds are a subset of hosts
V_TEMP=""
for i in $CFG_BUILD $CFG_HOST;
do
echo "$V_TEMP" | grep -qF $i || V_TEMP="$V_TEMP${V_TEMP:+ }$i"
done
CFG_HOST=$V_TEMP
2013-03-02 06:25:12 -06:00
# copy host-triples to target-triples so that hosts are a subset of targets
V_TEMP=""
2013-10-21 04:18:21 -05:00
for i in $CFG_HOST $CFG_TARGET;
2013-03-02 06:25:12 -06:00
do
echo "$V_TEMP" | grep -qF $i || V_TEMP="$V_TEMP${V_TEMP:+ }$i"
done
2013-10-21 04:18:21 -05:00
CFG_TARGET=$V_TEMP
2013-03-02 06:25:12 -06:00
# check target-specific tool-chains
2013-10-21 04:18:21 -05:00
for i in $CFG_TARGET
2013-03-02 06:25:12 -06:00
do
2013-03-25 01:36:34 -05:00
L_CHECK=false
2013-10-21 04:18:21 -05:00
for j in $CFG_SUPPORTED_TARGET
2013-03-25 01:36:34 -05:00
do
if [ $i = $j ]
then
L_CHECK=true
fi
done
if [ $L_CHECK = false ]
then
err "unsupported target triples \"$i\" found"
fi
2013-03-02 06:25:12 -06:00
case $i in
2015-07-20 18:39:47 -05:00
*android*)
2016-05-04 17:08:14 -05:00
case $i in
armv7-linux-androideabi)
cmd_prefix="arm-linux-androideabi"
;;
*)
cmd_prefix=$i
;;
esac
2015-07-20 18:39:47 -05:00
upper_snake_target=$(echo "$i" | tr '[:lower:]' '[:upper:]' | tr '\-' '\_')
eval ndk=\$"CFG_${upper_snake_target}_NDK"
if [ -z "$ndk" ]
2013-03-02 06:25:12 -06:00
then
2015-07-20 18:39:47 -05:00
ndk=$CFG_ANDROID_CROSS_PATH
eval "CFG_${upper_snake_target}_NDK"=$CFG_ANDROID_CROSS_PATH
warn "generic/default Android NDK option is deprecated (use --$i-ndk option instead)"
2013-03-02 06:25:12 -06:00
fi
2015-07-20 18:39:47 -05:00
# Perform a basic sanity check of the NDK
2016-05-04 17:08:14 -05:00
for android_ndk_tool in "$ndk/bin/$cmd_prefix-gcc" "$ndk/bin/$cmd_prefix-g++" "$ndk/bin/$cmd_prefix-ar"
2015-07-20 18:39:47 -05:00
do
if [ ! -f $android_ndk_tool ]
then
err "NDK tool $android_ndk_tool not found (bad or missing --$i-ndk option?)"
fi
done
2013-03-02 06:25:12 -06:00
;;
2015-12-15 15:34:06 -06:00
*-unknown-nacl)
if [ -z "$CFG_NACL_CROSS_PATH" ]
then
err "I need the NaCl SDK path! (use --nacl-cross-path)"
fi
;;
2013-10-31 14:36:27 -05:00
arm-apple-darwin)
if [ $CFG_OSTYPE != apple-darwin ]
then
err "The iOS target is only supported on Mac OS X"
fi
;;
2015-06-25 17:30:00 -05:00
*-msvc)
2015-08-27 12:16:31 -05:00
# There are three builds of cmake on windows: MSVC, MinGW and Cygwin
# The Cygwin build does not have generators for Visual Studio, so
# detect that here and error.
if ! "$CFG_CMAKE" --help | sed -n '/^Generators/,$p' | grep 'Visual Studio' > /dev/null
then
2015-09-10 16:41:14 -05:00
err "
cmake does not support Visual Studio generators.
This is likely due to it being an msys/cygwin build of cmake, \
rather than the required windows version, built using MinGW \
or Visual Studio.
If you are building under msys2 try installing the mingw-w64-x86_64-cmake \
package instead of cmake:
$ pacman -R cmake && pacman -S mingw-w64-x86_64-cmake
"
2015-08-27 12:16:31 -05:00
fi
2015-05-11 15:59:51 -05:00
# Use the REG program to figure out where VS is installed
# We need to figure out where cl.exe and link.exe are, so we do some
# munging and some probing here. We also look for the default
# INCLUDE and LIB variables for MSVC so we can set those in the
# build system as well.
2015-08-27 12:16:31 -05:00
install=$(cmd //c reg QUERY \
2015-07-23 21:38:00 -05:00
'HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0' \
2015-05-11 15:59:51 -05:00
-v InstallDir)
2015-07-23 21:38:00 -05:00
if [ -z "$install" ]; then
2015-08-27 12:16:31 -05:00
install=$(cmd //c reg QUERY \
2015-07-23 21:38:00 -05:00
'HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\12.0' \
-v InstallDir)
fi
2015-05-11 15:59:51 -05:00
need_ok "couldn't find visual studio install root"
CFG_MSVC_ROOT=$(echo "$install" | grep InstallDir | sed 's/.*REG_SZ[ ]*//')
CFG_MSVC_ROOT=$(dirname "$CFG_MSVC_ROOT")
CFG_MSVC_ROOT=$(dirname "$CFG_MSVC_ROOT")
2015-06-25 17:30:00 -05:00
putvar CFG_MSVC_ROOT
case $i in
x86_64-*)
bits=x86_64
msvc_part=amd64
;;
2016-03-29 11:33:08 -05:00
i*86-*)
2015-06-25 17:30:00 -05:00
bits=i386
msvc_part=
;;
*)
err "can only target x86 targets for MSVC"
;;
esac
bindir="${CFG_MSVC_ROOT}/VC/bin"
2015-07-26 16:18:30 -05:00
if [ -n "$msvc_part" ]; then
2015-06-25 17:30:00 -05:00
bindir="$bindir/$msvc_part"
fi
eval CFG_MSVC_BINDIR_$bits="\"$bindir\""
eval CFG_MSVC_CL_$bits="\"$bindir/cl.exe\""
eval CFG_MSVC_LIB_$bits="\"$bindir/lib.exe\""
eval CFG_MSVC_LINK_$bits="\"$bindir/link.exe\""
2015-05-11 15:59:51 -05:00
vcvarsall="${CFG_MSVC_ROOT}/VC/vcvarsall.bat"
2015-08-27 12:16:31 -05:00
include_path=$(cmd //V:ON //c "$vcvarsall" $msvc_part \& echo !INCLUDE!)
2015-05-11 15:59:51 -05:00
need_ok "failed to learn about MSVC's INCLUDE"
2015-08-27 12:16:31 -05:00
lib_path=$(cmd //V:ON //c "$vcvarsall" $msvc_part \& echo !LIB!)
2015-05-11 15:59:51 -05:00
need_ok "failed to learn about MSVC's LIB"
2015-06-25 17:30:00 -05:00
eval CFG_MSVC_INCLUDE_PATH_${bits}="\"$include_path\""
eval CFG_MSVC_LIB_PATH_${bits}="\"$lib_path\""
putvar CFG_MSVC_BINDIR_${bits}
putvar CFG_MSVC_CL_${bits}
putvar CFG_MSVC_LIB_${bits}
putvar CFG_MSVC_LINK_${bits}
putvar CFG_MSVC_INCLUDE_PATH_${bits}
putvar CFG_MSVC_LIB_PATH_${bits}
2015-05-11 15:59:51 -05:00
;;
2013-03-02 06:25:12 -06:00
*)
;;
esac
done
2011-12-02 18:04:17 -06:00
2016-06-27 18:02:06 -05:00
if [ "$CFG_OSTYPE" = "pc-windows-gnu" ] || [ "$CFG_OSTYPE" = "pc-windows-msvc" ]
then
# There are some MSYS python builds which will auto-translate
# windows-style paths to MSYS-style paths in Python itself.
# Unfortunately this breaks LLVM's build system as somewhere along
# the line LLVM prints a path into a file from Python and then CMake
# later tries to interpret that path. If Python prints a MSYS path
# and CMake tries to use it as a Windows path, you're gonna have a
# Bad Time.
#
# Consequently here we try to detect when that happens and print an
# error if it does.
if $CFG_PYTHON -c 'import sys; print sys.argv[1]' `pwd` | grep '^/' > /dev/null
then
err "
python is silently translating windows paths to MSYS paths \
and the build will fail if this python is used.
Either an official python install must be used or an \
alternative python package in MinGW must be used.
If you are building under msys2 try installing the mingw-w64-x86_64-python2 \
package instead of python2:
$ pacman -S mingw-w64-x86_64-python2
"
fi
fi
2015-07-26 16:18:30 -05:00
if [ -n "$CFG_PERF" ]
2012-01-16 05:20:07 -06:00
then
2012-02-28 23:02:12 -06:00
HAVE_PERF_LOGFD=`$CFG_PERF stat --log-fd 2>&1 | grep 'unknown option'`
2012-01-16 05:20:07 -06:00
if [ -z "$HAVE_PERF_LOGFD" ];
then
CFG_PERF_WITH_LOGFD=1
putvar CFG_PERF_WITH_LOGFD
fi
fi
2016-11-16 14:31:19 -06:00
if [ -n "$CFG_DISABLE_RUSTBUILD" ]; then
2011-11-01 17:22:07 -05:00
2016-02-12 18:40:06 -06:00
step_msg "making directories"
2011-09-21 10:46:18 -05:00
2016-02-12 18:40:06 -06:00
for i in \
doc doc/std doc/extra \
dl tmp dist
do
make_dir $i
done
2011-11-02 18:21:17 -05:00
2016-02-12 18:40:06 -06:00
for t in $CFG_HOST
do
make_dir $t/llvm
done
2011-11-01 19:28:41 -05:00
2016-02-12 18:40:06 -06:00
for t in $CFG_HOST
2011-11-01 18:50:47 -05:00
do
2016-02-12 18:40:06 -06:00
make_dir $t/rustllvm
2011-11-01 18:50:47 -05:00
done
2016-02-12 18:40:06 -06:00
for t in $CFG_TARGET
do
make_dir $t/rt
for s in 0 1 2 3
2011-09-23 12:50:06 -05:00
do
2016-02-12 18:40:06 -06:00
make_dir $t/rt/stage$s
make_dir $t/rt/jemalloc
make_dir $t/rt/compiler-rt
for i in \
isaac sync test \
arch/i386 arch/x86_64 arch/arm arch/aarch64 arch/mips arch/powerpc
do
make_dir $t/rt/stage$s/$i
done
2011-09-23 12:50:06 -05:00
done
2016-02-12 18:40:06 -06:00
done
2011-11-22 00:45:14 -06:00
2016-02-12 18:40:06 -06:00
for h in $CFG_HOST
do
for t in $CFG_TARGET
do
# host bin dir stage0
make_dir $h/stage0/bin
# host lib dir stage0
make_dir $h/stage0/lib
# host test dir stage0
make_dir $h/stage0/test
# target bin dir stage0
make_dir $h/stage0/lib/rustlib/$t/bin
# target lib dir stage0
make_dir $h/stage0/lib/rustlib/$t/lib
for i in 1 2 3
do
# host bin dir
make_dir $h/stage$i/bin
# host lib dir
make_dir $h/stage$i/$CFG_LIBDIR_RELATIVE
# host test dir
make_dir $h/stage$i/test
# target bin dir
make_dir $h/stage$i/$CFG_LIBDIR_RELATIVE/rustlib/$t/bin
# target lib dir
make_dir $h/stage$i/$CFG_LIBDIR_RELATIVE/rustlib/$t/lib
done
done
make_dir $h/test/run-pass
make_dir $h/test/run-pass-valgrind
make_dir $h/test/run-pass-fulldeps
make_dir $h/test/run-fail
make_dir $h/test/run-fail-fulldeps
make_dir $h/test/compile-fail
make_dir $h/test/parse-fail
make_dir $h/test/compile-fail-fulldeps
make_dir $h/test/bench
make_dir $h/test/perf
make_dir $h/test/pretty
make_dir $h/test/debuginfo-gdb
make_dir $h/test/debuginfo-lldb
make_dir $h/test/codegen
make_dir $h/test/codegen-units
make_dir $h/test/rustdoc
done
fi
2011-09-23 12:50:06 -05:00
2011-10-31 18:51:15 -05:00
# Configure submodules
step_msg "configuring submodules"
# Have to be in the top of src directory for this
2016-11-16 14:31:19 -06:00
if [ -z "$CFG_DISABLE_MANAGE_SUBMODULES" ] && [ -n "$CFG_DISABLE_RUSTBUILD" ]
2011-11-28 19:50:23 -06:00
then
2012-02-28 21:15:13 -06:00
cd ${CFG_SRC_DIR}
2012-04-30 17:40:04 -05:00
2012-02-28 21:15:13 -06:00
msg "git: submodule sync"
2013-07-17 03:50:22 -05:00
"${CFG_GIT}" submodule sync
2012-04-30 17:40:04 -05:00
2014-06-11 20:54:14 -05:00
msg "git: submodule init"
"${CFG_GIT}" submodule init
# Disable submodules that we're not using
2015-07-26 16:18:30 -05:00
if [ -n "${CFG_LLVM_ROOT}" ]; then
2014-06-11 20:54:14 -05:00
msg "git: submodule deinit src/llvm"
"${CFG_GIT}" submodule deinit src/llvm
fi
2015-07-26 16:18:30 -05:00
if [ -n "${CFG_JEMALLOC_ROOT}" ]; then
2014-06-11 20:54:14 -05:00
msg "git: submodule deinit src/jemalloc"
"${CFG_GIT}" submodule deinit src/jemalloc
fi
2012-04-30 17:40:04 -05:00
msg "git: submodule update"
2014-06-11 20:54:14 -05:00
"${CFG_GIT}" submodule update
2012-04-30 17:40:04 -05:00
need_ok "git failed"
2012-10-05 09:16:56 -05:00
msg "git: submodule foreach sync"
2013-07-17 03:50:22 -05:00
"${CFG_GIT}" submodule foreach --recursive 'if test -e .gitmodules; then git submodule sync; fi'
2012-10-05 09:16:56 -05:00
need_ok "git failed"
2012-10-05 13:04:45 -05:00
msg "git: submodule foreach update"
2014-06-11 20:54:14 -05:00
"${CFG_GIT}" submodule update --recursive
2012-10-05 13:04:45 -05:00
need_ok "git failed"
# NB: this is just for the sake of getting the submodule SHA1 values
# and status written into the build log.
msg "git: submodule status"
"${CFG_GIT}" submodule status --recursive
2012-04-30 17:40:04 -05:00
msg "git: submodule clobber"
2013-07-17 03:50:22 -05:00
"${CFG_GIT}" submodule foreach --recursive git clean -dxf
2012-04-30 17:40:04 -05:00
need_ok "git failed"
2013-07-17 03:50:22 -05:00
"${CFG_GIT}" submodule foreach --recursive git checkout .
2012-04-30 17:40:04 -05:00
need_ok "git failed"
2012-02-28 21:15:13 -06:00
cd ${CFG_BUILD_DIR}
2011-10-31 18:51:15 -05:00
fi
2016-04-29 14:32:18 -05:00
# Do a sanity check that the submodule source exists. Because GitHub
# automatically publishes broken tarballs that can't be disabled, and
# people download them and try to use them.
if [ ! -e "${CFG_SRC_DIR}/src/liblibc" ]; then
err "some submodules are missing. Is this a broken tarball?
If you downloaded this tarball from the GitHub release pages at
https://github.com/rust-lang/rust/releases,
then please delete it and instead download the source from
https://www.rust-lang.org/downloads.html"
fi
2012-02-28 21:15:13 -06:00
# Configure llvm, only if necessary
step_msg "looking at LLVM"
2012-03-26 18:05:33 -05:00
CFG_LLVM_SRC_DIR=${CFG_SRC_DIR}src/llvm/
2013-10-21 04:18:21 -05:00
for t in $CFG_HOST
2011-11-02 18:21:17 -05:00
do
2012-02-28 21:15:13 -06:00
do_reconfigure=1
2015-06-04 00:08:47 -05:00
is_msvc=0
case "$t" in
(*-msvc)
is_msvc=1
;;
esac
2012-02-28 21:15:13 -06:00
2016-11-16 14:31:19 -06:00
if [ -z "$CFG_DISABLE_RUSTBUILD" ]
2016-01-21 19:05:04 -06:00
then
msg "not configuring LLVM, rustbuild in use"
do_reconfigure=0
2016-12-02 11:25:43 -06:00
elif [ -z "$CFG_LLVM_ROOT" ]
2011-11-02 18:21:17 -05:00
then
2013-09-03 02:11:36 -05:00
LLVM_BUILD_DIR=${CFG_BUILD_DIR}$t/llvm
2016-06-01 19:41:27 -05:00
LLVM_INST_DIR=$LLVM_BUILD_DIR
2017-01-02 14:47:00 -06:00
# For some weird reason the MSVC output dir is different than Unix
2016-06-01 19:41:27 -05:00
if [ ${is_msvc} -ne 0 ]; then
if [ -n "$CFG_DISABLE_OPTIMIZE_LLVM" ]
then
# Just use LLVM straight from its build directory to
# avoid 'make install' time
LLVM_INST_DIR=$LLVM_BUILD_DIR/Debug
else
LLVM_INST_DIR=$LLVM_BUILD_DIR/Release
2015-06-04 00:08:47 -05:00
fi
2012-02-28 21:15:13 -06:00
fi
else
msg "not reconfiguring LLVM, external LLVM root"
# The user is using their own LLVM
LLVM_BUILD_DIR=
LLVM_INST_DIR=$CFG_LLVM_ROOT
do_reconfigure=0
2015-08-10 02:35:03 -05:00
# Check that LLVm FileCheck is available. Needed for the tests
2016-03-09 21:11:02 -06:00
if [ -z "$CFG_DISABLE_CODEGEN_TESTS" ]; then
need_cmd $LLVM_INST_DIR/bin/FileCheck
fi
2012-02-28 21:15:13 -06:00
fi
2011-11-02 18:21:17 -05:00
2012-02-28 21:15:13 -06:00
if [ ${do_reconfigure} -ne 0 ]
2011-11-10 17:54:31 -06:00
then
2012-02-28 21:15:13 -06:00
# because git is hilarious, it might have put the module index
# in a couple places.
index1="${CFG_SRC_DIR}.git/modules/src/llvm/index"
index2="${CFG_SRC_DIR}src/llvm/.git/index"
for index in ${index1} ${index2}
do
2013-09-06 02:09:36 -05:00
config_status="${LLVM_BUILD_DIR}/config.status"
2012-02-28 21:15:13 -06:00
if test -e ${index} -a \
-e ${config_status} -a \
${config_status} -nt ${index}
then
msg "not reconfiguring LLVM, config.status is fresh"
do_reconfigure=0
fi
done
2011-11-10 17:54:31 -06:00
fi
2012-02-28 21:15:13 -06:00
2015-10-23 11:31:12 -05:00
# We need the generator later on for compiler-rt even if LLVM's not built
2016-07-01 18:47:30 -05:00
if [ -n "$CFG_NINJA" ]
then
generator="Ninja"
elif [ ${is_msvc} -ne 0 ]
2015-05-11 16:03:45 -05:00
then
2015-07-23 21:38:00 -05:00
case "$CFG_MSVC_ROOT" in
*14.0*)
generator="Visual Studio 14 2015"
;;
*12.0*)
generator="Visual Studio 12 2013"
;;
*)
err "can't determine generator for LLVM cmake"
;;
esac
2015-06-25 17:30:00 -05:00
case "$t" in
x86_64-*)
2015-07-23 21:38:00 -05:00
generator="$generator Win64"
2015-06-25 17:30:00 -05:00
;;
i686-*)
;;
*)
err "can only build LLVM for x86 platforms"
;;
esac
2016-06-01 19:41:27 -05:00
else
generator="Unix Makefiles"
2015-05-11 16:03:45 -05:00
fi
2016-06-01 19:41:27 -05:00
CFG_CMAKE_GENERATOR=$generator
putvar CFG_CMAKE_GENERATOR
msg "configuring LLVM for $t"
LLVM_CFLAGS_32=""
LLVM_CXXFLAGS_32=""
LLVM_LDFLAGS_32=""
LLVM_CFLAGS_64=""
LLVM_CXXFLAGS_64=""
LLVM_LDFLAGS_64=""
case "$CFG_CC" in
("ccache clang")
LLVM_CXX_32="ccache"
LLVM_CC_32="ccache"
LLVM_CXX_32_ARG1="clang++"
LLVM_CC_32_ARG1="clang"
LLVM_CFLAGS_32="-Qunused-arguments"
LLVM_CXXFLAGS_32="-Qunused-arguments"
LLVM_CXX_64="ccache"
LLVM_CC_64="ccache"
LLVM_CXX_64_ARG1="clang++"
LLVM_CC_64_ARG1="clang"
LLVM_CFLAGS_64="-Qunused-arguments"
LLVM_CXXFLAGS_64="-Qunused-arguments"
2013-05-29 16:18:09 -05:00
;;
2016-06-01 19:41:27 -05:00
("clang")
LLVM_CXX_32="clang++"
LLVM_CC_32="clang"
LLVM_CFLAGS_32="-Qunused-arguments"
LLVM_CXXFLAGS_32="-Qunused-arguments"
LLVM_CXX_64="clang++"
LLVM_CC_64="clang"
LLVM_CFLAGS_64="-Qunused-arguments"
LLVM_CXXFLAGS_64="-Qunused-arguments"
2013-05-29 16:18:09 -05:00
;;
2016-06-01 19:41:27 -05:00
("ccache gcc")
LLVM_CXX_32="ccache"
LLVM_CC_32="ccache"
2016-10-11 12:08:07 -05:00
LLVM_CXX_32_ARG1="g++"
LLVM_CC_32_ARG1="gcc"
2016-06-01 19:41:27 -05:00
LLVM_CXX_64="ccache"
LLVM_CC_64="ccache"
LLVM_CXX_64_ARG1="g++"
LLVM_CC_64_ARG1="gcc"
2013-05-29 16:18:09 -05:00
;;
2016-06-01 19:41:27 -05:00
("gcc")
2016-12-12 13:36:52 -06:00
if [ -z "$CFG_ENABLE_SCCACHE" ]; then
LLVM_CXX_32="g++"
LLVM_CC_32="gcc"
2012-02-28 21:15:13 -06:00
2016-12-12 13:36:52 -06:00
LLVM_CXX_64="g++"
LLVM_CC_64="gcc"
else
LLVM_CXX_32="sccache"
LLVM_CC_32="sccache"
LLVM_CXX_32_ARG1="g++"
LLVM_CC_32_ARG1="gcc"
LLVM_CXX_64="sccache"
LLVM_CC_64="sccache"
LLVM_CXX_64_ARG1="g++"
LLVM_CC_64_ARG1="gcc"
fi
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 11:57:26 -05:00
;;
2016-06-01 19:41:27 -05:00
(*)
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 11:57:26 -05:00
msg "inferring LLVM_CXX/CC from CXX/CC = $CXX/$CC"
2015-07-26 16:18:30 -05:00
if [ -n "$CFG_ENABLE_CCACHE" ]
2015-07-13 19:29:01 -05:00
then
if [ -z "$CFG_CCACHE" ]
then
err "ccache requested but not found"
fi
2016-06-01 19:41:27 -05:00
LLVM_CXX_32="ccache"
LLVM_CC_32="ccache"
LLVM_CXX_32_ARG1="$CXX"
LLVM_CC_32_ARG1="$CC"
2015-07-13 19:29:01 -05:00
2016-06-01 19:41:27 -05:00
LLVM_CXX_64="ccache"
LLVM_CC_64="ccache"
LLVM_CXX_64_ARG1="$CXX"
LLVM_CC_64_ARG1="$CC"
2015-07-13 19:29:01 -05:00
else
LLVM_CXX_32="$CXX"
LLVM_CC_32="$CC"
LLVM_CXX_64="$CXX"
LLVM_CC_64="$CC"
fi
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 11:57:26 -05:00
;;
2016-06-01 19:41:27 -05:00
esac
2012-02-28 21:15:13 -06:00
2016-06-01 19:41:27 -05:00
case "$CFG_CPUTYPE" in
(x86*)
LLVM_CFLAGS_32="$LLVM_CFLAGS_32 -m32"
LLVM_CXXFLAGS_32="$LLVM_CXXFLAGS_32 -m32"
LLVM_LDFLAGS_32="$LLVM_LDFLAGS_32 -m32"
;;
esac
2012-02-28 21:15:13 -06:00
2016-06-01 19:41:27 -05:00
if echo $t | grep -q x86_64
then
LLVM_CXX=$LLVM_CXX_64
LLVM_CC=$LLVM_CC_64
LLVM_CXX_ARG1=$LLVM_CXX_64_ARG1
LLVM_CC_ARG1=$LLVM_CC_64_ARG1
LLVM_CFLAGS=$LLVM_CFLAGS_64
LLVM_CXXFLAGS=$LLVM_CXXFLAGS_64
LLVM_LDFLAGS=$LLVM_LDFLAGS_64
else
LLVM_CXX=$LLVM_CXX_32
LLVM_CC=$LLVM_CC_32
LLVM_CXX_ARG1=$LLVM_CXX_32_ARG1
LLVM_CC_ARG1=$LLVM_CC_32_ARG1
LLVM_CFLAGS=$LLVM_CFLAGS_32
LLVM_CXXFLAGS=$LLVM_CXXFLAGS_32
LLVM_LDFLAGS=$LLVM_LDFLAGS_32
fi
2014-05-28 01:37:46 -05:00
2016-06-01 19:41:27 -05:00
if [ "$CFG_USING_LIBCPP" != "0" ]; then
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_ENABLE_LIBCXX=ON"
fi
2014-05-28 01:37:46 -05:00
2016-06-01 19:41:27 -05:00
# Turn off things we don't need
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_INCLUDE_TESTS=OFF"
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_INCLUDE_EXAMPLES=OFF"
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_INCLUDE_DOCS=OFF"
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_ENABLE_ZLIB=OFF"
CMAKE_ARGS="$CMAKE_ARGS -DWITH_POLY=OFF"
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_ENABLE_TERMINFO=OFF"
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_ENABLE_LIBEDIT=OFF"
2014-05-28 01:37:46 -05:00
2016-06-01 19:41:27 -05:00
arch="$(echo "$t" | cut -d - -f 1)"
2012-02-28 21:15:13 -06:00
2016-06-01 19:41:27 -05:00
if [ "$arch" = i686 ]; then
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_BUILD_32_BITS=ON"
fi
2012-02-28 21:15:13 -06:00
2016-06-01 19:41:27 -05:00
if [ "$t" != "$CFG_BUILD" ]; then
2016-06-29 11:05:18 -05:00
# see http://llvm.org/docs/HowToCrossCompileLLVM.html
2016-06-01 19:41:27 -05:00
CMAKE_ARGS="$CMAKE_ARGS -DCMAKE_CROSSCOMPILING=True"
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_TARGET_ARCH=$arch"
2016-06-29 11:05:18 -05:00
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_TABLEGEN=$CFG_BUILD_DIR/$CFG_BUILD/llvm/bin/llvm-tblgen"
2016-06-01 19:41:27 -05:00
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_DEFAULT_TARGET_TRIPLE=$t"
fi
# MSVC handles compiler business itself
if [ ${is_msvc} -eq 0 ]; then
CMAKE_ARGS="$CMAKE_ARGS -DCMAKE_C_COMPILER=$LLVM_CC"
CMAKE_ARGS="$CMAKE_ARGS -DCMAKE_CXX_COMPILER=$LLVM_CXX"
CMAKE_ARGS="$CMAKE_ARGS '-DCMAKE_C_FLAGS=$LLVM_CFLAGS'"
CMAKE_ARGS="$CMAKE_ARGS '-DCMAKE_CXX_FLAGS=$LLVM_CXXFLAGS'"
if [ -n "$LLVM_CC_ARG1" ]; then
CMAKE_ARGS="$CMAKE_ARGS -DCMAKE_C_COMPILER_ARG1=$LLVM_CC_ARG1"
2012-02-28 21:15:13 -06:00
fi
2016-06-01 19:41:27 -05:00
if [ -n "$LLVM_CXX_ARG1" ]; then
CMAKE_ARGS="$CMAKE_ARGS -DCMAKE_CXX_COMPILER_ARG1=$LLVM_CXX_ARG1"
fi
# FIXME: What about LDFLAGS?
fi
2012-02-28 21:15:13 -06:00
2016-06-01 19:41:27 -05:00
if [ -n "$CFG_DISABLE_OPTIMIZE_LLVM" ]; then
CMAKE_ARGS="$CMAKE_ARGS -DCMAKE_BUILD_TYPE=Debug"
2016-11-13 12:38:10 -06:00
elif [ -n "$CFG_ENABLE_LLVM_RELEASE_DEBUGINFO" ]; then
2016-11-12 19:13:22 -06:00
CMAKE_ARGS="$CMAKE_ARGS -DCMAKE_BUILD_TYPE=RelWithDebInfo"
2016-06-01 19:41:27 -05:00
else
CMAKE_ARGS="$CMAKE_ARGS -DCMAKE_BUILD_TYPE=Release"
fi
if [ -z "$CFG_ENABLE_LLVM_ASSERTIONS" ]
then
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_ENABLE_ASSERTIONS=OFF"
else
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_ENABLE_ASSERTIONS=ON"
fi
2012-02-28 21:15:13 -06:00
2016-12-03 10:53:31 -06:00
CMAKE_ARGS="$CMAKE_ARGS -DLLVM_TARGETS_TO_BUILD='X86;ARM;AArch64;Mips;PowerPC;SystemZ;JSBackend;MSP430;Sparc'"
2016-06-01 19:41:27 -05:00
CMAKE_ARGS="$CMAKE_ARGS -G '$CFG_CMAKE_GENERATOR'"
CMAKE_ARGS="$CMAKE_ARGS $CFG_LLVM_SRC_DIR"
2014-05-28 01:32:07 -05:00
2016-06-01 19:41:27 -05:00
if [ ${do_reconfigure} -ne 0 ]
then
msg "configuring LLVM for $t with cmake"
2012-02-28 21:15:13 -06:00
msg "configuring LLVM with:"
2016-06-01 19:41:27 -05:00
msg "$CMAKE_ARGS"
2013-03-28 20:19:14 -05:00
2016-06-27 16:39:51 -05:00
(cd $LLVM_BUILD_DIR && eval "\"$CFG_CMAKE\"" $CMAKE_ARGS)
2016-06-01 19:41:27 -05:00
need_ok "LLVM cmake configure failed"
2011-11-02 18:21:17 -05:00
fi
2011-11-01 17:22:07 -05:00
2011-11-02 18:21:17 -05:00
# Construct variables for LLVM build and install directories for
# each target. These will be named
# CFG_LLVM_BUILD_DIR_${target_triple} but all the hyphens in
# target_triple will be converted to underscore, because bash
# variables can't contain hyphens. The makefile will then have to
# convert back.
CFG_LLVM_BUILD_DIR=$(echo CFG_LLVM_BUILD_DIR_${t} | tr - _)
CFG_LLVM_INST_DIR=$(echo CFG_LLVM_INST_DIR_${t} | tr - _)
eval ${CFG_LLVM_BUILD_DIR}="'$LLVM_BUILD_DIR'"
eval ${CFG_LLVM_INST_DIR}="'$LLVM_INST_DIR'"
2011-11-03 16:13:22 -05:00
done
step_msg "writing configuration"
putvar CFG_SRC_DIR
2015-06-12 12:40:07 -05:00
putvar CFG_SRC_DIR_RELATIVE
2011-11-03 16:13:22 -05:00
putvar CFG_BUILD_DIR
putvar CFG_OSTYPE
putvar CFG_CPUTYPE
putvar CFG_CONFIGURE_ARGS
2012-01-30 18:29:13 -06:00
putvar CFG_PREFIX
2013-10-21 04:18:21 -05:00
putvar CFG_HOST
putvar CFG_TARGET
2014-01-13 18:45:33 -06:00
putvar CFG_LIBDIR_RELATIVE
2012-02-29 13:48:29 -06:00
putvar CFG_DISABLE_MANAGE_SUBMODULES
2015-07-20 18:39:47 -05:00
putvar CFG_AARCH64_LINUX_ANDROID_NDK
putvar CFG_ARM_LINUX_ANDROIDEABI_NDK
2016-05-04 17:08:14 -05:00
putvar CFG_ARMV7_LINUX_ANDROIDEABI_NDK
2015-08-09 00:15:50 -05:00
putvar CFG_I686_LINUX_ANDROID_NDK
2015-12-15 15:34:06 -06:00
putvar CFG_NACL_CROSS_PATH
2013-10-21 04:18:21 -05:00
putvar CFG_MANDIR
2016-09-09 01:18:20 -05:00
putvar CFG_DOCDIR
2015-08-21 23:43:56 -05:00
putvar CFG_USING_LIBCPP
2013-10-21 04:18:21 -05:00
2013-05-29 16:18:09 -05:00
# Avoid spurious warnings from clang by feeding it original source on
# ccache-miss rather than preprocessed input.
2015-07-26 16:18:30 -05:00
if [ -n "$CFG_ENABLE_CCACHE" ] && [ -n "$CFG_USING_CLANG" ]
2013-05-29 16:18:09 -05:00
then
CFG_CCACHE_CPP2=1
putvar CFG_CCACHE_CPP2
fi
2015-07-26 16:18:30 -05:00
if [ -n "$CFG_ENABLE_CCACHE" ]
2013-05-30 09:26:12 -05:00
then
CFG_CCACHE_BASEDIR=${CFG_SRC_DIR}
putvar CFG_CCACHE_BASEDIR
fi
2011-11-03 16:13:22 -05:00
putvar CFG_LLVM_SRC_DIR
2013-10-21 04:18:21 -05:00
for t in $CFG_HOST
2011-11-03 16:13:22 -05:00
do
CFG_LLVM_BUILD_DIR=$(echo CFG_LLVM_BUILD_DIR_${t} | tr - _)
CFG_LLVM_INST_DIR=$(echo CFG_LLVM_INST_DIR_${t} | tr - _)
2011-11-02 18:21:17 -05:00
putvar $CFG_LLVM_BUILD_DIR
putvar $CFG_LLVM_INST_DIR
done
2011-11-01 17:22:07 -05:00
2016-11-16 14:31:19 -06:00
if [ -z "$CFG_DISABLE_RUSTBUILD" ]
2016-01-21 19:05:04 -06:00
then
INPUT_MAKEFILE=src/bootstrap/mk/Makefile.in
else
INPUT_MAKEFILE=Makefile.in
fi
2011-11-03 16:13:22 -05:00
msg
2016-01-21 19:05:04 -06:00
copy_if_changed ${CFG_SRC_DIR}${INPUT_MAKEFILE} ./Makefile
2012-02-28 14:05:05 -06:00
move_if_changed config.tmp config.mk
rm -f config.tmp
2012-03-26 19:58:43 -05:00
touch config.stamp
2011-03-16 19:36:49 -05:00
2015-04-08 16:21:36 -05:00
if [ -z "$CFG_ENABLE_DEBUG" ]; then
step_msg "configured in release mode. for development consider --enable-debug"
else
step_msg "complete"
fi
2016-12-08 17:09:20 -06:00
if [ "$CFG_SRC_DIR" = `pwd` ]; then
X_PY=x.py
else
X_PY=${CFG_SRC_DIR_RELATIVE}x.py
fi
2016-11-16 14:31:19 -06:00
if [ -z "$CFG_DISABLE_RUSTBUILD" ]; then
msg "NOTE you have now configured rust to use a rewritten build system"
msg " called rustbuild, and as a result this may have bugs that "
msg " you did not see before. If you experience any issues you can"
msg " go back to the old build system with --disable-rustbuild and"
msg " please feel free to report any bugs!"
msg ""
2016-12-08 17:09:20 -06:00
msg "run \`python ${X_PY} --help\`"
2016-11-16 14:31:19 -06:00
else
warn "the makefile-based build system is deprecated in favor of rustbuild"
msg ""
msg "It is recommended you avoid passing --disable-rustbuild to get your"
msg "build working as the makefiles will be deleted on 2017-02-02. If you"
msg "encounter bugs with rustbuild please file issues against rust-lang/rust"
msg ""
msg "run \`make help\`"
fi
2014-02-14 05:34:18 -06:00
msg