Before, the whitelist['nightly'] entries could contain lines that
didn't actually occur in the mozconfig. With this commit, we
require that all lines in the whitelist actually exist in the
mozconfig.
MozReview-Commit-ID: LdHfFAcBzgv
--HG--
extra : rebase_source : 0606dbe9641ec9fdb9de3148483bf6a3e00b0335
--enable-elf-hack is the default on all platforms where it's supported,
and is completely ignored on platforms where it's not supported.
While moving the flag to moz.configure, we're going to make it only
work on platforms where elfhack is supported, so we at least need to
remove it from mozconfigs for those platforms where it's not supported.
But generally speaking, we want less things in mozconfigs, so just
remove it from there, since it's the default anyways.
We currently turn off the C++14 sized-deallocation facility on MSVC, and
we'd like to ensure we do the same thing for clang and gcc. To do so,
we add new functionality to moz.configure for checking and adding
compilation flags, similar to the facility for checking and adding
warning flags. The newly added facility is then used to add
-fno-sized-deallocation to the compilation flags, when the option is
supported.
Once we do this, we can't define the sized deallocation functions in
mozalloc.h; the compiler will complain that we are using
-fno-sized-deallocation, yet defining these special functions that we'll
never use. These functions were added for MinGW, where we needed to
compile with C++14 ahead of other platforms to be compatible with MSVC
headers. But they're no longer necessary, though they would be if we
removed -fno-sized-deallocation; the compiler will complain if we do
that and we'll add them back at that point.
We have code to test whether particular flags are supported for the
compiler we're using. Unfortunately, that code is tied up with checking
for warning flags. We're about to add a separate facility for generic
compilation flags, and we'd like to avoid cutting and pasting code if
possible. Let's split the core code out into a separate, reusable function.
Our toolchain detection logic checks whether we can reuse the target
C (resp. C++) compiler for the host compiler. This is generally only
applicable in the not-cross-compiling case, but we had special logic to
check for clang in the cross-compiling case and accept it, as clang is
able to generate code for multiple architectures from a single compiler
binary.
Our recent switch to clang on Android has exposed a problem in this
logic: we would never check whether the target clang, compiling for the
host, could actually find the host's headers. This was especially
problematic on OS X hosts, where the host clang contains special logic
to grovel inside the XCode installation to find C++ headers. The clang
from the NDK, however, was ignorant of the XCode installation.
Therefore, the NDK clang would happily compile code for the host, even
including C headers for the host, but would be hopelessly lost when it
came to compiling C++ headers during the actual build.
In hopes of mitigating this, we now include a check for a representative
header for C and C++ when checking compilers for each of those
languages. This check will detect such problems as the above, and will
also alert people to potentially misconfigured compilers in other
situations.
We need to modify our test framework to cope with headers being
included, since our mock environment isn't actually equipped with a full
set of compilers and headers.
Now that extra_toolchain_flags includes stlport_cppflags, there's no
reason bindgen_cflags_defaults should depend on them both. So remove
the stlport_cppflags dependency. (There's no harm to multiply-including
stlport_cppflags, but not repeating -I options is good practice.)
extra_toolchain_flags is used for compiling target-specific bits of code
elsewhere in configure. Very shortly, we'll need to compile bits of
code that depend on the C++ standard library, so we'll want to point the
compiler at the C++ standard library. Making extra_toolchain_flags
include stlport_cppflags is the best way to do that.
extra_toolchain_flags is going to depend on stlport_cppflags
momentarily, so this commit is just for moving code around. Note that
the diff shows other things moving *after* stlport_cppflags.
We compute the same set of data in extra_toolchain_flags as we were
computing in bindgen_cflags_defaults. We might as well reuse the former
to compute the latter.
Hopefully this makes it more obvious how all of this is hooked
together.
MozReview-Commit-ID: 1jeyIZgHYht
--HG--
extra : rebase_source : 961474b1c19eacdcfe5ed2d90ba0d1b16a5a29c3
We currently have the logic for compare-mozconfigs spread across
2 Python files. I'd like to move the logic into 1 file so we
can do nicer things more easily. In preparation for this, change
compare-mozconfigs.py to receive an argument that is the path to
the topsrcdir. Also, switch to argparse because it is more modern.
MozReview-Commit-ID: 7oFQzAdmcim
--HG--
extra : rebase_source : 547cdac9dabf4fa22832648ac1838300d2d75c4a
Pretty sure this is a relic of running this check in automation
outside the context of a source check. compare-mozconfigs.py is
essentially a source lint. I don't see a need for this feature to
exist.
MozReview-Commit-ID: 1FUbJayg1sO
--HG--
extra : rebase_source : 48d8e9db9e04962eee90bbf5fcbd565c1bbbc9cb
We always passed this argument in so this change doesn't fix
any bugs. I just didn't like the code smell.
MozReview-Commit-ID: IXzj1gRbkJ6
--HG--
extra : rebase_source : cc8cec18cc7d7f0ab1a997065d1cc6cdd1d5c86d
We only call this function once. Behavior doesn't need to
be parameterized.
MozReview-Commit-ID: BR6WU4GSeyO
--HG--
extra : rebase_source : 873e3860efee3abb06e987c9747dfec4ba851e5a
Nobody passes in the "required" argument. Remove it and
functionality related to it.
MozReview-Commit-ID: IB8s4CiDy6a
--HG--
extra : rebase_source : 1eea96bb6f7ff15b97c72d2b7516db9f83dc0bdf
-Wc++14-compat warns about code whose meaning differs between C++11 and C++14. We want the new C++14 meanings, so we don't need to warn about these differences. We still want -Wc++1z-compat because we want to know about C++14 code whose meaning will change in C++17 or C++20.
MozReview-Commit-ID: 1CD11l2Fd86
--HG--
extra : rebase_source : 7bac029fd3e852fbb92f07e0358307c2c834ddc8
extra : source : 2d49767b136e420d39b88267f611fbe72ed0a3b8
The current code will fail if "RUSTC_OPT_LEVEL=" is passed. This can happen
if the value isn't present and that fact is injected into js' configure. We
only want to respect RUSTC_OPT_LEVEL if a value is passed, so we simply check
for the presence of a value rather than its origin.
MozReview-Commit-ID: 6GhLfprJEEn
--HG--
extra : rebase_source : 40f3e381a128e04d65cc0175df32cdcd8302e05e
David Major
Ciure Andrei
Christian Holler
Coroiu Cristina
Gregory Szorc
Tiberius Oros
Bob Owen
Kartikaya Gupta
Bill McCloskey
Nathan Froyd
Gurzau Raul
Mike Hommey
Alfredo.Yang
Brindusan Cristian
Tom Prince
André Bargull
arthur.iakab
Chris Peterson
Noemi Erli
Tom Ritter
John Lin
Chris Manchester
Andreea Pavel