The base compiler check in python configure does some preprocessing,
which ensures the compiler works to some extent. Autoconf used to have
a more complete test, doing a compile/link. We do have plenty of tests
afterwards that do that anyways, but it's better if we fail early if
the toolchain fails somehow.
This refactors try_compile such that the *_compiler variable themselves
can be used to trigger compiler tests. Eventually, we'll want something
similar for preprocessing and possibly other invocations.
This also removes similar tests from build/autoconf/toolchain.m4.
--HG--
extra : rebase_source : c60d1d6e39b6bd2a377516687affd9b8932ebc12
The base compiler check in python configure does some preprocessing,
which ensures the compiler works to some extent. Autoconf used to have
a more complete test, doing a compile/link. We do have plenty of tests
afterwards that do that anyways, but it's better if we fail early if
the toolchain fails somehow.
This refactors try_compile such that the *_compiler variable themselves
can be used to trigger compiler tests. Eventually, we'll want something
similar for preprocessing and possibly other invocations.
This also removes similar tests from build/autoconf/toolchain.m4 and
old-configure.in.
--HG--
extra : rebase_source : 4f6f84e5ad220386e9edf82d19cc2cd6c1f4c43e
We were unconditionally adding them, now actually check what the
compilers default to and add the flags if they are necessary.
This will, in the future, allow finer grained policy changes, where
we can decide that C++11 and C++14 are fine, downgrading compilers
that do C++17, etc.
At the same time, we improve things slightly by deriving HOST_CC from CC
in a smarter way, as well as CXX from CC, which we weren't doing
previously.
Many related things are not moved at the same time to keep the patch
somehow "small".
In bug 1254861, we unsupported clang < 3.3, picking 3.3 essentially
because that's the smallest version we had on automation. Bug 1254854
changed that, and the smallest version on automation is now 3.5.
Now, the motivation to unsupport an old version of clang again is that
recent versions don't have the problem with __float128 used in libstdc++
headers (bug 654493). In fact, starting with clang 3.4, the hack we have
in place is not necessary.
So let's just drop support for clang 3.3 instead of keeping that hack
around longer.
As mentioned in bug 1254854, Ubuntu 12.04 LTS has clang 3.4 packages.
Gonk, Android, and the generic cross-compilation setup all were using a
different yet similar way to prefix the toolchain. The latter was even
wrong, since the target and target alias usually don't match actual
toolchain prefixes (which don't include the machine part of the target).
Note that this removes force-setting cross_compiling to yes in
old-configure, which wasn't working because every AC_TRY_COMPILE
resets it with $ac_cv_prog_cc_cross or $ac_cv_prog_cxx_cross.
The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
I tested locally that both checks give the expected error if I
temporarily change the != to an =.
--HG--
extra : transplant_source : %01N%B9%8B%BC%1E%07%D6%AE%BA2%7B%87%FB%25Y%19%B6%A9%D3
The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
--HG--
extra : transplant_source : D%D3%FE%169%05%D0X%F3KK%17%9EW%88%BCs%9B%86%5D
It looks like overwriting AS here is not intentional. Before this patch,
it is impossible to override AS through mozconfig for anything that runs
past this stage in configure.
This patch does two things: 1. Treat clang on Windows explicitly as MSVC. There
are some places in our build system where we try to detect clang by looking at
the output of $(CC) -v, and that will cause us to believe that we are using
clang, which is not helpful. This patch defines the CLANG_CL variable when it
detects clang being used on Windows. It also masquarades clang-cl as MSVC
2012, which is how the compiler introduces itself through the _MSC_VER
predefined variable.
2. Disable a bunch of things which currently are not supported on clang-cl. As
we proceed with this port, hopefully we'll be able to remove everything in this
list, but this will get us closer to be able to build with clang-cl.
With this patch and clang-cl trunk, we can get past the configure stage of the
build.
--HG--
extra : rebase_source : e5b8d77e4571c936820cec858953d58b6f31e0d5
Mike Hommey
Mike Shal
Chris Manchester
Wes Kocher
L. David Baron
Bob Owen
Carsten "Tomcat" Book
Ehsan Akhgari
Trevor Saunders
Ted Mielczarek
Georg Koppen