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
According to https://developer.android.com/ndk/guides/abis.html,
androideabi-v7a must support vfpv3-d16. So we should use it for fpu flag.
MozReview-Commit-ID: 3rhmRTekmwD
--HG--
extra : rebase_source : c5ffa22d8712fc7b8006cc340175a9586d77f49b
The changesets in bug 1412932 changed the semantics for MOZ_PGO.
Before, it was effectively being set as an environment variable
by client.mk all the time. Afterwards - specifically after
2013c8dd1824 - the variable is set in mozconfigs via ac_add_options,
which means it is only exposed to configure, not the environment.
Investigation by dmajor revealed that -WX (warnings as errors) was
added to a js/src file's compiler invocation after the PGO code
refactor. (PGO and warnings as errors have a strange interaction
- bug 437002 - and should be disabled there.) Strangely, addition
of -WX was only present on Dev Edition PGO builds.
The reason for this is likely mozharness. Mozharness will export
the MOZ_PGO=1 environment variable for build configurations that
it knows are PGO. It appears to do this for all PGO build
configurations except Dev Edition. Since make and moz.configure
inherit environment variables, mozharness was basically papering
over the intended behavior change in 2013c8dd1824.
This commit fixes the problem by marking MOZ_PGO as a JS option
in moz.configure. This means `ac_add_options MOZ_PGO=1` (the new
convention for enabling PGO) will set MOZ_PGO for SpiderMonkey's
moz.configure.
Of course, MOZ_PGO=1 in an environment variable still works. And
mozharness's setting of this variable has the intended effect.
Eventually, I'd like to clean up the mozharness code so it is less
PGO aware and enables PGO via ac_add_options. But that's for another
day.
MozReview-Commit-ID: 1KYPJARI6SJ
--HG--
extra : amend_source : 5291cead9f1c1af9ed2a1f608af770bc8e4958c5
sccache.mk is the only thing that uses MOZ_PREFLIGHT_ALL and
MOZ_POSTFLIGHT_ALL. We're trying to kill client.mk and these
variables are next on the chopping block.
This commit essentially moves the logic of sccache.mk inline into
client.mk. Initially, I wanted to move the management of the
sccache daemon to Python as part of what `mach build` invokes.
However, the sccache daemon needs access to the make jobserver.
Since we don't have an active make process in `mach`, this is
obviously problematic. The sccache daemon is also used by
configure, which is launched from client.mk. So the best we
can do right now is move the sccache daemon logic into client.mk.
As part of the port, we pass the path to the sccache binary via
an environment variable. This feels slightly better than hardcoding
the path that automation uses.
MozReview-Commit-ID: zcOYR4I1OG
--HG--
extra : rebase_source : 305a237dc9f5bd96e4aa83d491ac2498fe3c3ba0
Add an intermediate step in old-configure.in for setting up
BINDGEN_CFLAGS (renamed to BINDGEN_SYSTEM_FLAGS), so we can add whatever
flags we like (e.g. for system libaries with their includes in
non-standard places) at a later point.
Stylo's bindgen is configured partially through a .toml.in file that
substitutes the value of a configure variable (BINDGEN_CFLAGS) into a
TOML list. We can debate whether this is a good thing to do some other
time; the reality is that the current moz.configure code that provides
the set_config for BINDGEN_CFLAGS needs to perform all the quoting
itself.
We want, however, to define the substituted variable in old-configure.in
land (some of the values that will go into BINDGEN_CFLAGS are only
defined in old-configure.in, and are not trivially ported to
moz.configure), which means that we need to have quoting logic in
m4/Python when we generate config.status. This patch adds an
appropriate macro for doing so.
The various AC_SUBST macros generate AC_SUBST_*FOO macros for holding the
values to substitute. The macros also cross-check the AC_SUBST_* macros
generated by other variants to make sure that you don't try to do
something like AC_SUBST(FOO) and AC_SUBST_SET(FOO). However, the check
in AC_SUBST_SET for AC_SUBST_LIST duplicate is missing an underscore:
the AC_SUBST_LIST macro generates another macro starting with
AC_SUBST_LIST_, but the AC_SUBST_SET macro checks for the prefix
AC_SUBST_LIST, which is missing the trailing underscore.
As we're going to be adding yet another AC_SUBST_* macro variant, and
therefore adding more checks to all existing macros, let's clean this up
before we start.
Before, I/O errors writing to stdout/stderr (e.g. due to broken pipe)
would result in handleError() being called and execution would
keep running. This would potentially result in an error message for
every log/line failure being printed to stderr.
We change the behavior so I/O failures are fatal and abort
execution.
We test the new behavior by changing a test to pipe to `head`
directly. Since `head` exits once it has seen sufficient output,
this results in an EPIPE which now results in immediate program
termination.
MozReview-Commit-ID: 1UecZJ56h4r
--HG--
extra : rebase_source : b35d9c096621d9698260d29a7d0132c4989200a7
We add a simple cram test that `configure --help` works.
I added the test to build/tests because I'm not sure where else it should go.
This test uncovers a few interesting things:
1) piping `./configure --help` to `head` directly causes a Python
traceback (presumably due to the pipe disappearing once N lines
have been read)
2) "checking for vcs source checkout" is printed for --help
3) It is printed twice (!!)
These will be addressed later. Establishing test coverage is
more important.
MozReview-Commit-ID: 9zQ5X8ulTkc
--HG--
extra : rebase_source : aaf660152cdfe37580f559976bca13ea9bf14c49
Before, the build root was not in a Docker cache or volume. With
current Docker works, that meant AUFS. We know AUFS is slow under
I/O load and can cause random failures due to missing data after
writes.
This commit changes the build root to a known Docker volume, which
will be backed by EXT4 and won't have the problems of AUFS.
MozReview-Commit-ID: 6WOH0yednAv
--HG--
extra : rebase_source : bbff0f00f55acdbe068fdf617a7903b8a303c397
This doesn't need to be in client.mk.
Also, we inline the info to help people correct the failure, as this
results in a better user experience.
MozReview-Commit-ID: KURL3RIGzKf
--HG--
extra : rebase_source : dc79d3f6aa4e91a12cab0e26d5fc0a3e15afa833
extra : source : 2eceb30625acd8cfadda0baa6326a7e9fd07dece
Checks like this are what configure is for.
In addition to moving the check, we also validate topobjdir as well.
MozReview-Commit-ID: 9sVNQJsAnjO
--HG--
extra : rebase_source : 688961fffca5922c7186c0d39182de7220f7dbe3
extra : source : d9a4ea9bc34a1e0c710469fc0a556ed624ea387b
compare-mozconfigs is platform agnostic AFAICT. And it runs fast.
Let's run tests for all the platforms all the time.
MozReview-Commit-ID: GqsFCp3XdZG
--HG--
extra : rebase_source : 4fd8fb48af61bfc95ec6c251ccf6fcf557ff6c0c
The mechanism by which PGO builds are kicked off is kinda wonky.
The MOZ_PGO environment variable is recognized by configure and setting
it will result in MOZ_PGO being defined in substs. In addition, the
build backend (previously client.mk, now Makefile.in) also recognizes
MOZ_PGO (from mozconfig or environment) and takes appropriate action.
In-tree mozconfigs set MOZ_PGO via mk_add_options. mk_add_options
is intended as a mechanism to inject state into client.mk and the
make-based build system.
In addition, there is code in mozharness (unchanged by this commit)
that sets MOZ_PGO if appropriate.
A PGO build configuration is different from a non-PGO build
configuration. Therefore a make-centric environment variable to
control PGO is not ideal. Instead, this should be defined as a
configure-time flag and the build invocation should key off that.
This commit normalizes in-tree mozconfigs to set MOZ_PGO via
ac_add_options and updates the PGO documentation to recommend
this method.
MozReview-Commit-ID: k6AZyJuXjs
--HG--
extra : rebase_source : b1a6348611eba08dd67ec938cca5586fbe8e6910
extra : source : 25c7ebc7c44dd253f421b6de3d0337635d0c99d0
32-bit clang-cl.exe was looking specifically for HostX86\x86\link.exe, which doesn't exist in our automation package. Make it look in HostX64\x86 instead.
This is an ugly hack and it would be preferable to just use a 64-bit compiler (bug 1414287).
In a proper VS install, the path to cl.exe looks like:
...\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64\cl.exe
In our automation, the path is just:
...\VC\bin\HostX64\x64\cl.exe
Clang tries to do some sanity-checking to make sure that the cl.exe it finds is the Microsoft compiler and not some other program. But the checks are a little too strict for us, so just look for "bin\Host*\*\cl.exe".
The new VS package is now based on update 15.4.2, although that release didn't affect any files in our package. I'm picking up the update mostly just to make filename unique.
There are xpcshell tests to verify that the appropriate distrust flag is set
upon reaching an affected end entity certificate; this test checks that the
distrust flag prints a warning to console.
MozReview-Commit-ID: OMG246WOOT
--HG--
rename : devtools/client/webconsole/test/browser_webconsole_certificate_messages.js => devtools/client/webconsole/test/browser_console_certificate_imminent_distrust.js
extra : rebase_source : a5fed5457e7789e742ee461b988463b81cd2c214
Currently mozconfig.cache overrides a few build options for sccache. This
patch moves them into toolchain.configure so that the build system will
set them properly when sccache is in use. Additionally, {CC,CXX}_WRAPPER
are set in config.mk, so just avoid setting them when sccache is in use.
MozReview-Commit-ID: FYlVKRI8OiN
--HG--
extra : rebase_source : 00715beb5fbd2c11311dec43809bd1febab56a11
extra : intermediate-source : 0f2b1b75b83737378d882a3c3e0d8dfb4efecd1f
extra : source : a8032ae9cb2ad1c4574c6ac6f5c2778863cd71e0
Coroiu Cristina
Gregory Szorc
Tiberius Oros
Bob Owen
Kartikaya Gupta
Bill McCloskey
David Major
Ciure Andrei
Nathan Froyd
Gurzau Raul
Mike Hommey
Alfredo.Yang
Brindusan Cristian
Tom Prince
André Bargull
arthur.iakab
Christian Holler
Chris Peterson
Noemi Erli
Tom Ritter
John Lin
Chris Manchester
Andreea Pavel
Robert Helmer
Makoto Kato
Ted Mielczarek
Ryan VanderMeulen
Margareta Eliza Balazs
Marco Castelluccio
Narcis Beleuzu
Randall Barker
Sylvestre Ledru
Sebastian Hengst
Masatoshi Kimura
J.C. Jones