2011-03-16 11:17:32 -05:00
|
|
|
#!/bin/sh
|
|
|
|
|
2011-03-18 01:51:45 -05:00
|
|
|
msg() {
|
|
|
|
echo "configure: $1"
|
|
|
|
}
|
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
|
|
|
|
}
|
|
|
|
|
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
|
2011-03-19 20:31:59 -05:00
|
|
|
then msg "found $1"
|
|
|
|
else err "need $1"
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2011-03-18 01:51:45 -05:00
|
|
|
make_dir() {
|
|
|
|
if [ ! -d $1 ]
|
|
|
|
then
|
|
|
|
msg "mkdir -p $1"
|
|
|
|
mkdir -p $1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2012-02-28 14:05:05 -06:00
|
|
|
copy_if_changed() {
|
|
|
|
if cmp -s $1 $2
|
|
|
|
then
|
|
|
|
msg "leaving $2 unchanged"
|
|
|
|
else
|
|
|
|
msg "cp $1 $2"
|
2012-02-28 20:41:54 -06:00
|
|
|
cp -f $1 $2
|
|
|
|
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
|
|
|
|
msg "mv $1 $2"
|
2012-02-28 20:41:54 -06:00
|
|
|
mv -f $1 $2
|
|
|
|
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
|
2012-04-10 05:25:59 -05:00
|
|
|
VER0=$($P --version 2>/dev/null | head -1 \
|
|
|
|
| sed -e 's/[^0-9]*\([vV]\?[0-9.]\+[^ ]*\).*/\1/' )
|
|
|
|
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() {
|
|
|
|
local V=$1
|
2012-01-19 15:08:01 -06:00
|
|
|
probe $*
|
2011-03-18 01:51:45 -05:00
|
|
|
eval VV=\$$V
|
|
|
|
if [ -z "$VV" ]
|
|
|
|
then
|
2012-01-19 15:08:01 -06:00
|
|
|
err "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}"
|
|
|
|
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
|
|
|
|
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"
|
|
|
|
else
|
|
|
|
FLAG="disable"
|
|
|
|
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}"
|
|
|
|
eval $V=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
|
2011-03-29 23:45:09 -05:00
|
|
|
fi
|
|
|
|
done
|
|
|
|
else
|
|
|
|
if [ ! -z "$META" ]
|
|
|
|
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.
|
|
|
|
if [ ! -z "$VV" ]
|
|
|
|
then
|
|
|
|
putvar $V
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2014-07-23 13:56:36 -05:00
|
|
|
to_llvm_triple() {
|
|
|
|
case $1 in
|
|
|
|
i686-w64-mingw32) echo i686-pc-windows-gnu ;;
|
|
|
|
x86_64-w64-mingw32) echo x86_64-pc-windows-gnu ;;
|
|
|
|
*) echo $1 ;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
;;
|
|
|
|
|
2011-09-21 13:24:59 -05:00
|
|
|
Darwin)
|
|
|
|
CFG_OSTYPE=apple-darwin
|
|
|
|
;;
|
|
|
|
|
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
|
|
|
|
;;
|
|
|
|
|
2013-03-22 20:21:43 -05:00
|
|
|
# Thad's Cygwin identifers below
|
|
|
|
|
|
|
|
# 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
|
|
|
|
;;
|
|
|
|
|
|
|
|
# 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
|
|
|
|
;;
|
|
|
|
|
2014-05-28 01:42:35 -05:00
|
|
|
armv7l)
|
|
|
|
CFG_CPUTYPE=arm
|
|
|
|
CFG_OSTYPE="${CFG_OSTYPE}eabihf"
|
|
|
|
;;
|
|
|
|
|
2014-12-12 17:39:27 -06:00
|
|
|
aarch64)
|
|
|
|
CFG_CPUTYPE=aarch64
|
|
|
|
;;
|
|
|
|
|
2015-01-09 21:49:54 -06:00
|
|
|
powerpc)
|
|
|
|
CFG_CPUTYPE=powerpc
|
|
|
|
;;
|
|
|
|
|
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
|
|
|
;;
|
|
|
|
|
|
|
|
*)
|
|
|
|
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
|
|
|
|
file -L "$SHELL" | grep -q "x86[_-]64"
|
|
|
|
if [ $? != 0 ]; then
|
|
|
|
CFG_CPUTYPE=i686
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
2013-10-21 04:18:21 -05:00
|
|
|
DEFAULT_BUILD="${CFG_CPUTYPE}-${CFG_OSTYPE}"
|
2011-09-21 13:24:59 -05:00
|
|
|
|
2012-04-30 17:40:04 -05:00
|
|
|
CFG_SRC_DIR="$(cd $(dirname $0) && pwd)/"
|
|
|
|
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="$@"
|
|
|
|
|
2011-03-29 23:45:09 -05:00
|
|
|
OPTIONS=""
|
|
|
|
HELP=0
|
|
|
|
if [ "$1" = "--help" ]
|
|
|
|
then
|
|
|
|
HELP=1
|
|
|
|
shift
|
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=""
|
|
|
|
|
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"
|
2011-03-29 23:45:09 -05:00
|
|
|
opt docs 1 "build documentation"
|
2011-04-08 17:44:41 -05:00
|
|
|
opt optimize 1 "build optimized rust code"
|
2011-11-11 12:24:58 -06:00
|
|
|
opt optimize-cxx 1 "build optimized C++ code"
|
2011-11-11 13:21:26 -06:00
|
|
|
opt optimize-llvm 1 "build optimized LLVM"
|
2013-08-11 02:29:45 -05:00
|
|
|
opt optimize-tests 1 "build tests with optimizations"
|
2014-05-28 19:04:14 -05:00
|
|
|
opt libcpp 1 "build with llvm with libc++ instead of libstdc++ when using clang"
|
2013-07-31 01:34:01 -05:00
|
|
|
opt llvm-assertions 1 "build LLVM with assertions"
|
2013-09-17 23:02:11 -05:00
|
|
|
opt debug 1 "build with extra debug fun"
|
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"
|
2012-04-05 17:40:34 -05:00
|
|
|
opt local-rust 0 "use an installed rustc rather than downloading a snapshot"
|
2014-04-16 12:45:04 -05:00
|
|
|
opt llvm-static-stdcpp 0 "statically link to libstdc++ for LLVM"
|
2014-06-11 16:52:38 -05:00
|
|
|
opt rpath 0 "build rpaths into rustc itself"
|
2014-03-25 23:33:44 -05:00
|
|
|
opt nightly 0 "build nightly packages"
|
2014-03-28 04:43:31 -05:00
|
|
|
opt verify-install 1 "verify installed binaries work"
|
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"
|
|
|
|
opt jemalloc 1 "build liballoc with jemalloc"
|
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"
|
|
|
|
valopt jemalloc-root "" "set directory where libjemalloc_pic.a is located"
|
|
|
|
valopt build "${DEFAULT_BUILD}" "GNUs ./configure syntax LLVM build triple"
|
|
|
|
valopt android-cross-path "/opt/ndk_standalone" "Android NDK standalone path"
|
|
|
|
|
|
|
|
# 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"
|
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"
|
|
|
|
valopt_nosave release-channel "dev" "the name of the release channel to build"
|
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
|
|
|
|
2014-07-23 13:56:36 -05:00
|
|
|
# Temporarily support old triples until buildbots get updated
|
|
|
|
CFG_BUILD=$(to_llvm_triple $CFG_BUILD)
|
|
|
|
putvar CFG_BUILD # Yes, this creates a duplicate entry, but the last one wins.
|
|
|
|
CFG_HOST=$(to_llvm_triple $CFG_HOST)
|
|
|
|
CFG_TARGET=$(to_llvm_triple $CFG_TARGET)
|
|
|
|
|
2014-01-07 10:51:15 -06:00
|
|
|
# On windows we just store the libraries in the bin directory because
|
2014-03-25 20:18:57 -05:00
|
|
|
# there's no rpath. This is where the build system itself puts libraries;
|
|
|
|
# --libdir is used to configure the installation directory.
|
2014-09-25 18:40:10 -05:00
|
|
|
# FIXME: This needs to parameterized over target triples. Do it in platform.mk
|
2014-07-23 13:56:36 -05:00
|
|
|
if [ "$CFG_OSTYPE" = "pc-windows-gnu" ]
|
2014-01-07 10:51:15 -06:00
|
|
|
then
|
2014-01-13 18:45:33 -06:00
|
|
|
CFG_LIBDIR_RELATIVE=bin
|
2014-08-17 01:23:36 -05:00
|
|
|
else
|
2014-11-23 08:36:36 -06:00
|
|
|
CFG_LIBDIR_RELATIVE=lib
|
|
|
|
fi
|
2014-08-17 01:23:36 -05:00
|
|
|
|
2014-11-23 08:36:36 -06:00
|
|
|
valopt libdir "${CFG_PREFIX}/${CFG_LIBDIR_RELATIVE}" "install libraries (do not set it on windows platform)"
|
|
|
|
|
|
|
|
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
|
|
|
|
2014-11-23 08:36:36 -06:00
|
|
|
if [ "$CFG_OSTYPE" = "pc-windows-gnu" ] && [ "$CFG_LIBDIR_RELATIVE" != "bin" ]; then
|
|
|
|
err "libdir on windows should be set to 'bin'"
|
2014-08-17 01:23:36 -05:00
|
|
|
fi
|
2013-10-21 04:18:21 -05: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
|
|
|
|
step_msg "validating $CFG_SELF args"
|
|
|
|
validate_opt
|
2011-03-16 19:36:49 -05: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
|
|
|
# Validate the release channel
|
|
|
|
case "$CFG_RELEASE_CHANNEL" in
|
2014-09-25 17:28:00 -05:00
|
|
|
(dev | nightly | beta | 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
|
|
|
;;
|
|
|
|
(*)
|
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
|
|
|
|
|
|
|
|
# Continue supporting the old --enable-nightly flag to transition the bots
|
|
|
|
# XXX Remove me
|
2014-09-25 15:34:16 -05:00
|
|
|
if [ ! -z "$CFG_ENABLE_NIGHTLY" ]
|
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
|
|
|
then
|
|
|
|
CFG_RELEASE_CHANNEL=nightly
|
|
|
|
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
|
|
|
putvar CFG_RELEASE_CHANNEL
|
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
|
|
|
|
Preliminary feature staging
This partially implements the feature staging described in the
[release channel RFC][rc]. It does not yet fully conform to the RFC as
written, but does accomplish its goals sufficiently for the 1.0 alpha
release.
It has three primary user-visible effects:
* On the nightly channel, use of unstable APIs generates a warning.
* On the beta channel, use of unstable APIs generates a warning.
* On the beta channel, use of feature gates generates a warning.
Code that does not trigger these warnings is considered 'stable',
modulo pre-1.0 bugs.
Disabling the warnings for unstable APIs continues to be done in the
existing (i.e. old) style, via `#[allow(...)]`, not that specified in
the RFC. I deem this marginally acceptable since any code that must do
this is not using the stable dialect of Rust.
Use of feature gates is itself gated with the new 'unstable_features'
lint, on nightly set to 'allow', and on beta 'warn'.
The attribute scheme used here corresponds to an older version of the
RFC, with the `#[staged_api]` crate attribute toggling the staging
behavior of the stability attributes, but the user impact is only
in-tree so I'm not concerned about having to make design changes later
(and I may ultimately prefer the scheme here after all, with the
`#[staged_api]` crate attribute).
Since the Rust codebase itself makes use of unstable features the
compiler and build system to a midly elaborate dance to allow it to
bootstrap while disobeying these lints (which would otherwise be
errors because Rust builds with `-D warnings`).
This patch includes one significant hack that causes a
regression. Because the `format_args!` macro emits calls to unstable
APIs it would trigger the lint. I added a hack to the lint to make it
not trigger, but this in turn causes arguments to `println!` not to be
checked for feature gates. I don't presently understand macro
expansion well enough to fix. This is bug #20661.
Closes #16678
[rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
2015-01-06 08:26:08 -06:00
|
|
|
# A magic value that allows the compiler to use unstable features
|
|
|
|
# during the bootstrap even when doing so would normally be an error
|
|
|
|
# because of feature staging or because the build turns on
|
|
|
|
# warnings-as-errors and unstable features default to warnings. The
|
|
|
|
# build has to match this key in an env var. Meant to be a mild
|
|
|
|
# deterrent from users just turning on unstable features on the stable
|
|
|
|
# channel.
|
|
|
|
# Basing CFG_BOOTSTRAP_KEY on CFG_BOOTSTRAP_KEY lets it get picked up
|
|
|
|
# during a Makefile reconfig.
|
2015-01-17 00:39:04 -06:00
|
|
|
CFG_BOOTSTRAP_KEY="${CFG_BOOTSTRAP_KEY-`date +%H:%M:%S`}"
|
Preliminary feature staging
This partially implements the feature staging described in the
[release channel RFC][rc]. It does not yet fully conform to the RFC as
written, but does accomplish its goals sufficiently for the 1.0 alpha
release.
It has three primary user-visible effects:
* On the nightly channel, use of unstable APIs generates a warning.
* On the beta channel, use of unstable APIs generates a warning.
* On the beta channel, use of feature gates generates a warning.
Code that does not trigger these warnings is considered 'stable',
modulo pre-1.0 bugs.
Disabling the warnings for unstable APIs continues to be done in the
existing (i.e. old) style, via `#[allow(...)]`, not that specified in
the RFC. I deem this marginally acceptable since any code that must do
this is not using the stable dialect of Rust.
Use of feature gates is itself gated with the new 'unstable_features'
lint, on nightly set to 'allow', and on beta 'warn'.
The attribute scheme used here corresponds to an older version of the
RFC, with the `#[staged_api]` crate attribute toggling the staging
behavior of the stability attributes, but the user impact is only
in-tree so I'm not concerned about having to make design changes later
(and I may ultimately prefer the scheme here after all, with the
`#[staged_api]` crate attribute).
Since the Rust codebase itself makes use of unstable features the
compiler and build system to a midly elaborate dance to allow it to
bootstrap while disobeying these lints (which would otherwise be
errors because Rust builds with `-D warnings`).
This patch includes one significant hack that causes a
regression. Because the `format_args!` macro emits calls to unstable
APIs it would trigger the lint. I added a hack to the lint to make it
not trigger, but this in turn causes arguments to `println!` not to be
checked for feature gates. I don't presently understand macro
expansion well enough to fix. This is bug #20661.
Closes #16678
[rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
2015-01-06 08:26:08 -06:00
|
|
|
putvar CFG_BOOTSTRAP_KEY
|
|
|
|
|
2011-03-29 23:45:09 -05:00
|
|
|
step_msg "looking for build programs"
|
2011-11-03 16:13:22 -05:00
|
|
|
|
2013-06-29 21:22:20 -05:00
|
|
|
probe_need CFG_CURLORWGET curl wget
|
2012-06-25 19:18:09 -05:00
|
|
|
probe_need CFG_PYTHON python2.7 python2.6 python2 python
|
|
|
|
|
|
|
|
python_version=$($CFG_PYTHON -V 2>&1)
|
|
|
|
if [ $(echo $python_version | grep -c '^Python 2\.[4567]') -ne 1 ]; then
|
|
|
|
err "Found $python_version, but LLVM requires Python 2.4-2.7"
|
|
|
|
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
|
|
|
|
|
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_JAVAC javac
|
|
|
|
probe CFG_ANTLR4 antlr4
|
|
|
|
probe CFG_GRUN grun
|
2012-01-12 21:10:30 -06:00
|
|
|
probe CFG_PANDOC pandoc
|
|
|
|
probe CFG_PDFLATEX pdflatex
|
2014-03-09 05:21:05 -05:00
|
|
|
probe CFG_XELATEX xelatex
|
|
|
|
probe CFG_LUALATEX lualatex
|
2013-02-10 16:17:28 -06:00
|
|
|
probe CFG_GDB gdb
|
2014-04-24 04:35:48 -05:00
|
|
|
probe CFG_LLDB lldb
|
|
|
|
|
2014-08-20 05:53:50 -05:00
|
|
|
if [ ! -z "$CFG_GDB" ]
|
|
|
|
then
|
2014-10-02 04:35:24 -05:00
|
|
|
# Store GDB's version
|
2014-08-20 05:53:50 -05:00
|
|
|
CFG_GDB_VERSION=$($CFG_GDB --version 2>/dev/null | head -1)
|
|
|
|
putvar CFG_GDB_VERSION
|
|
|
|
fi
|
|
|
|
|
2014-04-24 04:35:48 -05:00
|
|
|
if [ ! -z "$CFG_LLDB" ]
|
|
|
|
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
|
|
|
|
|
2013-05-03 10:46:52 -05:00
|
|
|
step_msg "looking for target specific programs"
|
|
|
|
|
|
|
|
probe CFG_ADB adb
|
|
|
|
|
2012-01-18 16:32:15 -06:00
|
|
|
if [ ! -z "$CFG_PANDOC" ]
|
|
|
|
then
|
2014-11-06 05:56:16 -06:00
|
|
|
PV_MAJOR_MINOR=$(pandoc --version | grep '^pandoc\(.exe\)\? ' |
|
2013-03-25 08:09:52 -05:00
|
|
|
# extract the first 2 version fields, ignore everything else
|
2014-11-06 05:56:16 -06:00
|
|
|
sed 's/pandoc\(.exe\)\? \([0-9]*\)\.\([0-9]*\).*/\2 \3/')
|
2013-03-25 08:09:52 -05:00
|
|
|
|
2013-11-01 00:06:13 -05:00
|
|
|
MIN_PV_MAJOR="1"
|
|
|
|
MIN_PV_MINOR="9"
|
2013-03-25 08:09:52 -05:00
|
|
|
# these patterns are shell globs, *not* regexps
|
|
|
|
PV_MAJOR=${PV_MAJOR_MINOR% *}
|
|
|
|
PV_MINOR=${PV_MAJOR_MINOR#* }
|
2013-11-01 00:06:13 -05:00
|
|
|
if [ "$PV_MAJOR" -lt "$MIN_PV_MAJOR" ] || [ "$PV_MINOR" -lt "$MIN_PV_MINOR" ]
|
2012-01-18 16:32:15 -06:00
|
|
|
then
|
2013-12-13 10:33:50 -06:00
|
|
|
step_msg "pandoc $PV_MAJOR.$PV_MINOR is too old. Need at least $MIN_PV_MAJOR.$MIN_PV_MINOR. Disabling"
|
|
|
|
BAD_PANDOC=1
|
2012-01-18 16:32:15 -06:00
|
|
|
fi
|
2012-10-03 20:46:32 -05:00
|
|
|
fi
|
|
|
|
|
2013-11-20 21:29:40 -06:00
|
|
|
BIN_SUF=
|
2014-07-23 13:56:36 -05:00
|
|
|
if [ "$CFG_OSTYPE" = "pc-windows-gnu" ]
|
2013-11-20 21:29:40 -06:00
|
|
|
then
|
|
|
|
BIN_SUF=.exe
|
|
|
|
fi
|
|
|
|
|
2012-04-19 17:46:09 -05:00
|
|
|
if [ ! -z "$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}"
|
|
|
|
LRV=`$CMD --version`
|
|
|
|
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
|
|
|
|
|
2012-11-14 16:27:45 -06:00
|
|
|
# Force freebsd to build with clang; gcc doesn't like us there
|
|
|
|
if [ $CFG_OSTYPE = unknown-freebsd ]
|
|
|
|
then
|
|
|
|
step_msg "on FreeBSD, forcing use of clang"
|
|
|
|
CFG_ENABLE_CLANG=1
|
|
|
|
fi
|
|
|
|
|
2011-11-03 14:01:31 -05:00
|
|
|
if [ -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
|
2011-05-08 23:10:04 -05:00
|
|
|
then
|
|
|
|
err "either clang or gcc is required"
|
|
|
|
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
|
|
|
|
step_msg "on OS X 10.9, forcing use of clang"
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
if [ ! -z "$CFG_ENABLE_CLANG" ]
|
|
|
|
then
|
|
|
|
putvar CFG_ENABLE_CLANG
|
|
|
|
fi
|
|
|
|
|
2011-05-18 21:32:18 -05:00
|
|
|
if [ ! -z "$CFG_LLVM_ROOT" -a -e "$CFG_LLVM_ROOT/bin/llvm-config" ]
|
|
|
|
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
|
2014-08-21 17:39:18 -05:00
|
|
|
(3.[2-6]*)
|
2013-12-13 10:33:50 -06:00
|
|
|
msg "found ok version of LLVM: $LLVM_VERSION"
|
|
|
|
;;
|
|
|
|
(*)
|
|
|
|
err "bad LLVM version: $LLVM_VERSION, need >=3.0svn"
|
|
|
|
;;
|
2011-11-02 16:07:32 -05:00
|
|
|
esac
|
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.
|
|
|
|
|
|
|
|
if [ ! -z "$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
|
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 "$CFG_ENABLE_CLANG" ]
|
|
|
|
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
|
|
|
|
|
|
|
|
if [ ! -z "$CFG_ENABLE_CLANG" ]
|
|
|
|
then
|
|
|
|
if [ -z "$CC" ] || [[ $CC == *clang ]]
|
|
|
|
then
|
|
|
|
CFG_CLANG_VERSION=$($CFG_CC \
|
|
|
|
--version \
|
|
|
|
| grep version \
|
|
|
|
| sed 's/.*\(version .*\)/\1/; s/.*based on \(LLVM .*\))/\1/' \
|
|
|
|
| cut -d ' ' -f 2)
|
|
|
|
|
|
|
|
case $CFG_CLANG_VERSION in
|
2014-09-07 16:42:48 -05:00
|
|
|
(3.0svn | 3.0 | 3.1* | 3.2* | 3.3* | 3.4* | 3.5* | 3.6*)
|
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 "found ok version of CLANG: $CFG_CLANG_VERSION"
|
|
|
|
if [ -z "$CC" ]
|
|
|
|
then
|
|
|
|
CFG_CC="clang"
|
2014-05-27 04:48:32 -05:00
|
|
|
CFG_CXX="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
|
|
|
fi
|
|
|
|
;;
|
|
|
|
(*)
|
|
|
|
err "bad CLANG version: $CFG_CLANG_VERSION, need >=3.0svn"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
else
|
|
|
|
msg "skipping CFG_ENABLE_CLANG version check; provided CC=$CC"
|
|
|
|
fi
|
2011-05-18 23:41:40 -05:00
|
|
|
fi
|
2011-09-23 12:50:06 -05:00
|
|
|
|
2013-05-29 16:18:09 -05:00
|
|
|
if [ ! -z "$CFG_ENABLE_CCACHE" ]
|
|
|
|
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
|
|
|
if [ -z "$CC" ]
|
2013-05-29 16:18:09 -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
|
|
|
if [ -z "$CFG_CCACHE" ]
|
|
|
|
then
|
|
|
|
err "ccache requested but not found"
|
|
|
|
fi
|
|
|
|
|
|
|
|
CFG_CC="ccache $CFG_CC"
|
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
|
|
|
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.
|
|
|
|
|
|
|
|
# Set CFG_{CC,CXX,CPP,CFLAGS,CXXFLAGS}
|
|
|
|
envopt CC
|
|
|
|
envopt CXX
|
|
|
|
envopt CPP
|
|
|
|
envopt CFLAGS
|
|
|
|
envopt CXXFLAGS
|
|
|
|
|
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%/}
|
|
|
|
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
|
|
|
|
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
|
2013-03-25 01:36:34 -05:00
|
|
|
arm-linux-androideabi)
|
2013-03-02 06:25:12 -06:00
|
|
|
|
|
|
|
if [ ! -f $CFG_ANDROID_CROSS_PATH/bin/arm-linux-androideabi-gcc ]
|
|
|
|
then
|
|
|
|
err "NDK $CFG_ANDROID_CROSS_PATH/bin/arm-linux-androideabi-gcc not found"
|
|
|
|
fi
|
|
|
|
if [ ! -f $CFG_ANDROID_CROSS_PATH/bin/arm-linux-androideabi-g++ ]
|
|
|
|
then
|
|
|
|
err "NDK $CFG_ANDROID_CROSS_PATH/bin/arm-linux-androideabi-g++ not found"
|
|
|
|
fi
|
|
|
|
if [ ! -f $CFG_ANDROID_CROSS_PATH/bin/arm-linux-androideabi-ar ]
|
|
|
|
then
|
|
|
|
err "NDK $CFG_ANDROID_CROSS_PATH/bin/arm-linux-androideabi-ar not found"
|
|
|
|
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
|
|
|
|
;;
|
|
|
|
|
2013-03-02 06:25:12 -06:00
|
|
|
*)
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
done
|
2011-12-02 18:04:17 -06:00
|
|
|
|
2012-01-16 05:20:07 -06:00
|
|
|
if [ ! -z "$CFG_PERF" ]
|
|
|
|
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
|
|
|
|
|
2011-09-21 10:46:18 -05:00
|
|
|
step_msg "making directories"
|
2011-11-01 17:22:07 -05:00
|
|
|
|
2011-09-21 10:46:18 -05:00
|
|
|
for i in \
|
2013-05-17 12:45:09 -05:00
|
|
|
doc doc/std doc/extra \
|
2014-03-09 16:10:42 -05:00
|
|
|
dl tmp dist
|
2011-09-21 10:46:18 -05:00
|
|
|
do
|
|
|
|
make_dir $i
|
|
|
|
done
|
|
|
|
|
2013-10-21 04:18:21 -05:00
|
|
|
for t in $CFG_HOST
|
2011-11-02 18:21:17 -05:00
|
|
|
do
|
2013-09-03 02:11:36 -05:00
|
|
|
make_dir $t/llvm
|
2011-11-02 18:21:17 -05:00
|
|
|
done
|
|
|
|
|
2013-10-21 04:18:21 -05:00
|
|
|
for t in $CFG_HOST
|
2011-11-01 19:28:41 -05:00
|
|
|
do
|
2013-09-04 01:48:45 -05:00
|
|
|
make_dir $t/rustllvm
|
2011-11-01 19:28:41 -05:00
|
|
|
done
|
|
|
|
|
2013-10-21 04:18:21 -05:00
|
|
|
for t in $CFG_TARGET
|
2011-11-01 18:50:47 -05:00
|
|
|
do
|
2013-09-04 02:45:01 -05:00
|
|
|
make_dir $t/rt
|
2013-05-24 01:49:20 -05:00
|
|
|
for s in 0 1 2 3
|
2011-11-01 18:50:47 -05:00
|
|
|
do
|
2013-09-04 02:45:01 -05:00
|
|
|
make_dir $t/rt/stage$s
|
2014-04-25 01:19:34 -05:00
|
|
|
make_dir $t/rt/jemalloc
|
2013-05-24 01:49:20 -05:00
|
|
|
for i in \
|
2013-10-16 21:51:51 -05:00
|
|
|
isaac sync test \
|
2015-01-09 21:49:54 -06:00
|
|
|
arch/i386 arch/x86_64 arch/arm arch/aarch64 arch/mips arch/powerpc
|
2013-05-24 01:49:20 -05:00
|
|
|
do
|
2013-09-04 02:45:01 -05:00
|
|
|
make_dir $t/rt/stage$s/$i
|
2013-05-24 01:49:20 -05:00
|
|
|
done
|
2011-11-01 18:50:47 -05:00
|
|
|
done
|
|
|
|
done
|
|
|
|
|
2013-10-24 23:57:56 -05:00
|
|
|
for h in $CFG_HOST
|
2011-09-23 12:50:06 -05:00
|
|
|
do
|
2013-10-21 04:18:21 -05:00
|
|
|
for t in $CFG_TARGET
|
2011-09-23 12:50:06 -05:00
|
|
|
do
|
2014-08-17 01:23:36 -05:00
|
|
|
# host lib dir stage0
|
|
|
|
make_dir $h/stage0/lib
|
|
|
|
|
|
|
|
# target bin dir stage0
|
|
|
|
make_dir $h/stage0/lib/rustlib/$t/bin
|
|
|
|
|
|
|
|
# target lib dir stage0
|
|
|
|
make_dir $h/stage0/lib/rustlib/$t/lib
|
|
|
|
|
2011-11-21 15:11:40 -06:00
|
|
|
for i in 0 1 2 3
|
|
|
|
do
|
|
|
|
# host bin dir
|
|
|
|
make_dir $h/stage$i/bin
|
2011-09-23 12:50:06 -05:00
|
|
|
|
2011-11-21 15:11:40 -06:00
|
|
|
# host lib dir
|
2014-01-13 18:45:33 -06:00
|
|
|
make_dir $h/stage$i/$CFG_LIBDIR_RELATIVE
|
2011-09-23 12:50:06 -05:00
|
|
|
|
2013-05-13 17:19:48 -05:00
|
|
|
# host test dir
|
|
|
|
make_dir $h/stage$i/test
|
|
|
|
|
2011-11-21 15:11:40 -06:00
|
|
|
# target bin dir
|
2014-03-25 20:18:57 -05:00
|
|
|
make_dir $h/stage$i/$CFG_LIBDIR_RELATIVE/rustlib/$t/bin
|
2011-09-30 18:55:18 -05:00
|
|
|
|
2011-11-21 15:11:40 -06:00
|
|
|
# target lib dir
|
2014-03-25 20:18:57 -05:00
|
|
|
make_dir $h/stage$i/$CFG_LIBDIR_RELATIVE/rustlib/$t/lib
|
2011-11-21 15:11:40 -06:00
|
|
|
done
|
2011-09-23 12:50:06 -05:00
|
|
|
done
|
2011-11-22 00:45:14 -06:00
|
|
|
|
|
|
|
make_dir $h/test/run-pass
|
2014-10-07 02:00:26 -05:00
|
|
|
make_dir $h/test/run-pass-valgrind
|
2012-06-01 18:01:53 -05:00
|
|
|
make_dir $h/test/run-pass-fulldeps
|
2011-11-22 00:45:14 -06:00
|
|
|
make_dir $h/test/run-fail
|
|
|
|
make_dir $h/test/compile-fail
|
2014-04-28 19:31:43 -05:00
|
|
|
make_dir $h/test/compile-fail-fulldeps
|
2011-11-22 00:45:14 -06:00
|
|
|
make_dir $h/test/bench
|
|
|
|
make_dir $h/test/perf
|
|
|
|
make_dir $h/test/pretty
|
2014-04-24 04:35:48 -05:00
|
|
|
make_dir $h/test/debuginfo-gdb
|
|
|
|
make_dir $h/test/debuginfo-lldb
|
2013-07-06 03:03:03 -05:00
|
|
|
make_dir $h/test/codegen
|
2011-09-23 12:50:06 -05:00
|
|
|
done
|
|
|
|
|
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
|
2011-11-28 19:50:23 -06:00
|
|
|
if [ -z $CFG_DISABLE_MANAGE_SUBMODULES ]
|
|
|
|
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
|
|
|
|
if [ ! -z "${CFG_LLVM_ROOT}" ]; then
|
|
|
|
msg "git: submodule deinit src/llvm"
|
|
|
|
"${CFG_GIT}" submodule deinit src/llvm
|
|
|
|
fi
|
|
|
|
if [ ! -z "${CFG_JEMALLOC_ROOT}" ]; then
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
2011-11-02 18:21:17 -05:00
|
|
|
if [ -z $CFG_LLVM_ROOT ]
|
|
|
|
then
|
2013-09-03 02:11:36 -05:00
|
|
|
LLVM_BUILD_DIR=${CFG_BUILD_DIR}$t/llvm
|
2012-02-28 21:15:13 -06:00
|
|
|
if [ ! -z "$CFG_DISABLE_OPTIMIZE_LLVM" ]
|
|
|
|
then
|
2013-02-26 19:30:32 -06:00
|
|
|
LLVM_DBG_OPTS="--enable-debug-symbols --disable-optimized"
|
2012-02-28 21:15:13 -06:00
|
|
|
# Just use LLVM straight from its build directory to
|
|
|
|
# avoid 'make install' time
|
2013-07-31 01:34:01 -05:00
|
|
|
LLVM_INST_DIR=$LLVM_BUILD_DIR/Debug
|
2012-02-28 21:15:13 -06:00
|
|
|
else
|
|
|
|
LLVM_DBG_OPTS="--enable-optimized"
|
2013-07-31 01:34:01 -05:00
|
|
|
LLVM_INST_DIR=$LLVM_BUILD_DIR/Release
|
|
|
|
fi
|
|
|
|
if [ ! -z "$CFG_DISABLE_LLVM_ASSERTIONS" ]
|
|
|
|
then
|
|
|
|
LLVM_ASSERTION_OPTS="--disable-assertions"
|
|
|
|
else
|
|
|
|
LLVM_ASSERTION_OPTS="--enable-assertions"
|
|
|
|
LLVM_INST_DIR=${LLVM_INST_DIR}+Asserts
|
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
|
|
|
|
fi
|
2011-11-02 18:21:17 -05:00
|
|
|
|
2011-11-11 13:21:26 -06: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
|
|
|
|
|
|
|
if [ ${do_reconfigure} -ne 0 ]
|
|
|
|
then
|
2014-07-23 13:56:36 -05:00
|
|
|
# LLVM's configure doesn't recognize the new Windows triples yet
|
|
|
|
gnu_t=$(to_gnu_triple $t)
|
|
|
|
|
|
|
|
msg "configuring LLVM for $gnu_t"
|
2012-02-28 21:15:13 -06:00
|
|
|
|
2015-01-09 21:49:54 -06:00
|
|
|
LLVM_TARGETS="--enable-targets=x86,x86_64,arm,aarch64,mips,powerpc"
|
2014-07-23 13:56:36 -05:00
|
|
|
LLVM_BUILD="--build=$gnu_t"
|
|
|
|
LLVM_HOST="--host=$gnu_t"
|
|
|
|
LLVM_TARGET="--target=$gnu_t"
|
2012-02-28 21:15:13 -06:00
|
|
|
|
|
|
|
# Disable unused LLVM features
|
2013-07-31 01:34:01 -05:00
|
|
|
LLVM_OPTS="$LLVM_DBG_OPTS $LLVM_ASSERTION_OPTS --disable-docs --enable-bindings=none"
|
2013-09-21 20:01:11 -05:00
|
|
|
# Disable term-info, linkage of which comes in multiple forms,
|
|
|
|
# making our snapshots incompatible (#9334)
|
|
|
|
LLVM_OPTS="$LLVM_OPTS --disable-terminfo"
|
2013-09-23 12:06:29 -05:00
|
|
|
# Try to have LLVM pull in as few dependencies as possible (#9397)
|
|
|
|
LLVM_OPTS="$LLVM_OPTS --disable-zlib --disable-libffi"
|
2012-02-28 21:15:13 -06:00
|
|
|
|
2013-12-16 12:39:44 -06:00
|
|
|
# Use win32 native thread/lock apis instead of pthread wrapper.
|
|
|
|
# (llvm's configure tries to find pthread first, so we have to disable it explicitly.)
|
|
|
|
# Also note that pthreads works badly on mingw-w64 systems: #8996
|
2013-11-23 23:21:35 -06:00
|
|
|
case "$CFG_BUILD" in
|
2014-07-23 13:56:36 -05:00
|
|
|
(*-windows-*)
|
2013-11-23 23:21:35 -06:00
|
|
|
LLVM_OPTS="$LLVM_OPTS --disable-pthreads"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
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
|
|
|
case "$CFG_CC" in
|
2013-05-29 16:18:09 -05:00
|
|
|
("ccache clang")
|
2014-05-28 01:37:46 -05:00
|
|
|
LLVM_CXX_32="ccache clang++ -Qunused-arguments"
|
|
|
|
LLVM_CC_32="ccache clang -Qunused-arguments"
|
2013-05-29 16:18:09 -05:00
|
|
|
|
|
|
|
LLVM_CXX_64="ccache clang++ -Qunused-arguments"
|
|
|
|
LLVM_CC_64="ccache clang -Qunused-arguments"
|
|
|
|
;;
|
|
|
|
("clang")
|
2014-05-28 01:37:46 -05:00
|
|
|
LLVM_CXX_32="clang++ -Qunused-arguments"
|
|
|
|
LLVM_CC_32="clang -Qunused-arguments"
|
2012-02-28 21:15:13 -06:00
|
|
|
|
2013-12-02 12:08:45 -06:00
|
|
|
LLVM_CXX_64="clang++ -Qunused-arguments"
|
|
|
|
LLVM_CC_64="clang -Qunused-arguments"
|
2013-05-29 16:18:09 -05:00
|
|
|
;;
|
|
|
|
("ccache gcc")
|
2014-05-28 01:37:46 -05:00
|
|
|
LLVM_CXX_32="ccache g++"
|
|
|
|
LLVM_CC_32="ccache gcc"
|
2013-05-29 16:18:09 -05:00
|
|
|
|
|
|
|
LLVM_CXX_64="ccache g++"
|
|
|
|
LLVM_CC_64="ccache gcc"
|
|
|
|
;;
|
|
|
|
("gcc")
|
2014-05-28 01:37:46 -05:00
|
|
|
LLVM_CXX_32="g++"
|
|
|
|
LLVM_CC_32="gcc"
|
2012-02-28 21:15:13 -06:00
|
|
|
|
|
|
|
LLVM_CXX_64="g++"
|
|
|
|
LLVM_CC_64="gcc"
|
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"
|
2014-05-28 01:37:46 -05:00
|
|
|
LLVM_CXX_32="$CXX"
|
|
|
|
LLVM_CC_32="$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
|
|
|
|
|
|
|
LLVM_CXX_64="$CXX"
|
|
|
|
LLVM_CC_64="$CC"
|
|
|
|
;;
|
2013-05-29 16:18:09 -05:00
|
|
|
esac
|
2012-02-28 21:15:13 -06:00
|
|
|
|
2014-05-28 01:37:46 -05:00
|
|
|
case "$CFG_CPUTYPE" in
|
|
|
|
(x86*)
|
|
|
|
LLVM_CXX_32="$LLVM_CXX_32 -m32"
|
|
|
|
LLVM_CC_32="$LLVM_CC_32 -m32"
|
2012-02-28 21:15:13 -06:00
|
|
|
|
2014-05-28 01:37:46 -05:00
|
|
|
LLVM_CFLAGS_32="-m32"
|
|
|
|
LLVM_CXXFLAGS_32="-m32"
|
|
|
|
LLVM_LDFLAGS_32="-m32"
|
|
|
|
|
|
|
|
LLVM_CFLAGS_64=""
|
|
|
|
LLVM_CXXFLAGS_64=""
|
|
|
|
LLVM_LDFLAGS_64=""
|
|
|
|
|
|
|
|
LLVM_CXX_32="$LLVM_CXX_32 -m32"
|
|
|
|
LLVM_CC_32="$LLVM_CC_32 -m32"
|
|
|
|
;;
|
|
|
|
|
|
|
|
(*)
|
|
|
|
LLVM_CFLAGS_32=""
|
|
|
|
LLVM_CXXFLAGS_32=""
|
|
|
|
LLVM_LDFLAGS_32=""
|
2012-02-28 21:15:13 -06:00
|
|
|
|
2014-05-28 01:37:46 -05:00
|
|
|
LLVM_CFLAGS_64=""
|
|
|
|
LLVM_CXXFLAGS_64=""
|
|
|
|
LLVM_LDFLAGS_64=""
|
|
|
|
;;
|
|
|
|
esac
|
2012-02-28 21:15:13 -06:00
|
|
|
|
|
|
|
if echo $t | grep -q x86_64
|
|
|
|
then
|
|
|
|
LLVM_CXX=$LLVM_CXX_64
|
|
|
|
LLVM_CC=$LLVM_CC_64
|
|
|
|
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_CFLAGS=$LLVM_CFLAGS_32
|
|
|
|
LLVM_CXXFLAGS=$LLVM_CXXFLAGS_32
|
|
|
|
LLVM_LDFLAGS=$LLVM_LDFLAGS_32
|
|
|
|
fi
|
|
|
|
|
|
|
|
CXX=$LLVM_CXX
|
|
|
|
CC=$LLVM_CC
|
|
|
|
CFLAGS=$LLVM_CFLAGS
|
|
|
|
CXXFLAGS=$LLVM_CXXFLAGS
|
|
|
|
LDFLAGS=$LLVM_LDFLAGS
|
|
|
|
|
2014-06-05 08:17:59 -05:00
|
|
|
if [ -z "$CFG_DISABLE_LIBCPP" ] && [ -n "$CFG_USING_CLANG" ]; then
|
2014-05-28 01:32:07 -05:00
|
|
|
LLVM_OPTS="$LLVM_OPTS --enable-libcpp"
|
|
|
|
fi
|
|
|
|
|
2012-02-28 21:15:13 -06:00
|
|
|
LLVM_FLAGS="$LLVM_TARGETS $LLVM_OPTS $LLVM_BUILD \
|
2013-04-11 13:46:48 -05:00
|
|
|
$LLVM_HOST $LLVM_TARGET --with-python=$CFG_PYTHON"
|
2012-02-28 21:15:13 -06:00
|
|
|
|
|
|
|
msg "configuring LLVM with:"
|
|
|
|
msg "$LLVM_FLAGS"
|
|
|
|
|
|
|
|
export CXX
|
|
|
|
export CC
|
|
|
|
export CFLAGS
|
|
|
|
export CXXFLAGS
|
|
|
|
export LDFLAGS
|
|
|
|
|
|
|
|
cd $LLVM_BUILD_DIR
|
|
|
|
case $CFG_SRC_DIR in
|
|
|
|
/* | [a-z]:* | [A-Z]:*)
|
2012-03-26 18:05:33 -05:00
|
|
|
${CFG_LLVM_SRC_DIR}configure $LLVM_FLAGS
|
2012-02-28 21:15:13 -06:00
|
|
|
;;
|
|
|
|
*)
|
2012-03-26 18:05:33 -05:00
|
|
|
${CFG_BUILD_DIR}${CFG_LLVM_SRC_DIR}configure \
|
2012-02-28 21:15:13 -06:00
|
|
|
$LLVM_FLAGS
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
need_ok "LLVM configure failed"
|
2013-03-28 20:19:14 -05:00
|
|
|
|
2012-02-28 21:15:13 -06:00
|
|
|
cd $CFG_BUILD_DIR
|
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
|
|
|
|
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
|
2014-07-23 13:56:36 -05:00
|
|
|
putvar CFG_ANDROID_CROSS_PATH
|
2013-10-21 04:18:21 -05:00
|
|
|
putvar CFG_MANDIR
|
|
|
|
|
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.
|
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 "$CFG_ENABLE_CCACHE" ] && [ ! -z "$CFG_USING_CLANG" ]
|
2013-05-29 16:18:09 -05:00
|
|
|
then
|
|
|
|
CFG_CCACHE_CPP2=1
|
|
|
|
putvar CFG_CCACHE_CPP2
|
|
|
|
fi
|
|
|
|
|
2013-05-30 09:26:12 -05:00
|
|
|
if [ ! -z "$CFG_ENABLE_CCACHE" ]
|
|
|
|
then
|
|
|
|
CFG_CCACHE_BASEDIR=${CFG_SRC_DIR}
|
|
|
|
putvar CFG_CCACHE_BASEDIR
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
2012-01-18 16:32:15 -06:00
|
|
|
if [ ! -z $BAD_PANDOC ]
|
|
|
|
then
|
|
|
|
CFG_PANDOC=
|
|
|
|
putvar CFG_PANDOC
|
|
|
|
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
|
|
|
|
|
|
|
# Munge any paths that appear in config.mk back to posix-y
|
2015-01-15 02:31:22 -06:00
|
|
|
sed -i.bak -e 's@ \([a-zA-Z]\):[/\\]@ /\1/@g;' config.tmp
|
2012-02-28 14:05:05 -06:00
|
|
|
rm -f config.tmp.bak
|
2011-10-31 18:51:15 -05:00
|
|
|
|
2011-11-03 16:13:22 -05:00
|
|
|
msg
|
2012-02-28 14:05:05 -06:00
|
|
|
copy_if_changed ${CFG_SRC_DIR}Makefile.in ./Makefile
|
|
|
|
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
|
|
|
|
2011-03-29 23:45:09 -05:00
|
|
|
step_msg "complete"
|
2014-02-14 21:17:50 -06:00
|
|
|
msg "run \`make help\`"
|
2014-02-14 05:34:18 -06:00
|
|
|
msg
|