One of the last remaining differences when building Firefox on Debian
with all the changes we've done so far is that linking against the
system libc statically links some CRT objects. This causes massive
differences in the resulting binaries because of slight differences
in those objects (because they weren't compiled with the same compiler
and because they're not for the exact same glibc version)
In practice, their content difference don't cause any problem. If they
did, we wouldn't be able to run our builds on newer systems than those
we build them on. The only hypothetical risk would be to run on systems
with a glibc older than Debian 7's, but those already can't run Firefox
anyways (those systems don't have Gtk+3, which is a system requirement).
AFAICT, this is only an hypothetical problem anyways, even such systems
with Gtk+3 should be able to run those builds. Plus, this is a change
that will happen anyways when switching to Debian-based build images,
since they would be using the CRT objects from there. We're merely
making it happen earlier so that the differences from switching to
Debian-based build images are more tractable.
Note we only do this when building GCC on Debian, allowing to roll back
to CentOS-based toolchains by just switching back the toolchain jobs to
use the desktop-build docker image again.
When building on Debian (which we now are), this means we enable
.init_array/.fini_array.
When building on CentOS, this means no change. Which implies we could
roll back to CentOS-based toolchains by just switching back the
toolchain jobs to use the desktop-build docker image again.
This change causes massive differences in the resulting binaries because
of the offset differences, but practically speaking, there is no
difference. .init_array/.fini_array have been supported in glibc for 18
years.
We believe this is another spurious memcheck error triggered
by code from Rust 1.23.0. See also bug 1394696.
For some reason, this error occurs both with and without
the leading underscore on mangled std::sync::once methods,
so this change matches either with a wildcard.
MozReview-Commit-ID: 4upSAPqAtNA
--HG--
extra : rebase_source : 5f697aaa5e170369f08d385d10c1aac9d8c1e50b
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
We build packages of the same versions that were installed by
taskcluster/docker/recipes/install-cmake.sh and
taskcluster/docker/centos6-build/system-setup.sh in the desktop-build
image.
--HG--
extra : rebase_source : 843b89065daabd450f54ebf7a2cf55d00977e23a
Currently, the build can finish succesfully even when one of the
programs fails to build and is not included in the final artifact. The
macosx build then fails because of that, which is the wrong place to
be failing.
--HG--
extra : rebase_source : 4a41b2f96eea45d3eefa2734900603b6e6ee0ea5
There are multiple methods with the same name and that differ in their
arguments. They end up being ordered in the source file randomly,
despite there being some sorting done, because the sorting was only done
on the method name.
Now, when the method name matches, also compare the arguments.
--HG--
extra : rebase_source : a89b8c9dbad1d7506e0068119ba25cd34150bafc
The Python version validation in virtualenv.py is only called in 2
locations: `python -m mozbuild.virtualenv` and in moz.configure.
I believe that nobody calls `python -m mozbuild.virtualenv` any more.
That means that moz.configure is the only caller of
verify_python_version(). That means we can inline the logic into
moz.configure.
It makes sense for version checking to live in moz.configure because
the role of moz.configure is to evaluate the sanity of the environment.
So this commit does just that.
MozReview-Commit-ID: 7FLL0cGblFS
--HG--
extra : rebase_source : 4c2ecbe06399aad917f58ffb25a571993b736965
Recent refactoring made the wrapper pretty useless. Since I'm about
to look at this code once more, let's remove it while we're here.
MozReview-Commit-ID: GA9cKeLH7Iu
--HG--
extra : rebase_source : 9e08ed60eab694a9f20385aa5f85a9909809b199
The system binutils and gcc are built with that option on Debian, but
not on CentOS. That makes no practical difference, except for the fact
that when building GCC, we use our own-built binutils (as per bug
1427316), but use the system GCC. And a GCC built with --with-sysroot=/
doesn't work with a binutils built without. However, a GCC built without
--with-sysroot=/ works fine with a binutils built with it. So this
change is compatible with building our GCC on both CentOS and Debian.
We currently use a 32-bit Rust toolchain for win32 builds, but this can lead
to OOM situations. This patch makes win32 builds use a 64-bit Rust toolchain,
which requires a little bit of extra configuration because rustc needs to
be able to find a link.exe that produces 64-bit binaries for building
things like build scripts, which are host binaries.
We will now generate a batch file that sets LIB to the paths to 64-bit
libraries and invokes the x64-targeting link.exe, and add a section to the
.cargo/config file to instruct cargo to use that batch file as the linker
when producing 64-bit binaries.
MozReview-Commit-ID: 9vKBbm7Gvra
--HG--
extra : rebase_source : 273a99be71914167664482c2bdb26c840ec6867b
mk_add_options has this kind of awkward feature where
mk_add_options VAR=value
would set VAR for the build through client.mk, but not when running
make -C objdir target. But
mk_add_options "export VAR=value"
does.
We might want to change that on the long run, but the side effects would
have to be calculated first.
OTOH, we have automation jobs that run compilations during `make check`
(e.g. rusttests), which is not invoked through client.mk. So they
currently don't get the same PATH as the build part, meaning that
they're using system binutils instead of the one from the GCC toolchain
package.
--HG--
extra : rebase_source : aab7f221243c486cf70c7b0c91b9313231050ed8
We no longer support Android/armv6 and we requires NEON for Android/arm, so
we can remove armv6 support for Android.
MozReview-Commit-ID: Hh17BTyE0wR
--HG--
extra : rebase_source : 57e043ecb1bb57a026c0b656b82768b899ddae78
I was able to reproduce the failure to apply llvm-dsymutil on the last
mozilla-central revision before debug info was temporarily disabled for
rust, and validated that the problem was gone in clang 4.
After some bisection, r289565 was identified as having fixed the
problem, which, reading the commit message, makes sense.
It was however not possible to simply cherry-pick, because of multiple
code changes between 3.9 and 4. However, apart from the volume of
conflicting changes, it was more or less straightforward to backport.
Interestingly, the patch for r313872 was relying on changes from
r289565, which is why it required a variant specifically for 3.9, but
now we can use the same patch as for other versions. Well, except
there's a small difference in the context, and build-clang.py doesn't
allow fuzz, so we manually edit the patch to remove that line from the
context.
--HG--
extra : rebase_source : de0ab262d401c37c0e9300b0ef7923a07c009d87
In bug 1426785, Gtk+3 build was moved to docker image creation time, and
at the same time, the removal of .la files was stripped, because it
seemed too broad to do that in /usr/local/lib*, and because I didn't
really remember why it was there in the first place.
I now do remember, and that's because libtool likes to add useless
dependencies on libraries just because direct dependencies transitively
depend on them. For example, this adds a dependency on libffi to
libpangocairo, which doesn't use it directly.
I also happens that /usr/local/lib* is empty at the moment we build
gtk3, so we can just do the cleanup there.
On its own, this change is useless, but:
- it restores the libraries in their state pre-bug 1426785,
- it helps reduce some differences when building on Debian (for bug
1399679), easing the comparison of those builds.
--HG--
extra : rebase_source : 3fa644d8ae5eb4ccac5940c7d3605201f589936d
I was able to reproduce the failure to apply llvm-dsymutil on the last
mozilla-central revision before debug info was temporarily disabled for
rust, and validated that the problem was gone in clang 4.
After some bisection, r289565 was identified as having fixed the
problem, which, reading the commit message, makes sense.
It was however not possible to simply cherry-pick, because of multiple
code changes between 3.9 and 4. However, apart from the volume of
conflicting changes, it was more or less straightforward to backport.
Interestingly, the patch for r313872 was relying on changes from
r289565, which is why it required a variant specifically for 3.9, but
now we can use the same patch as for other versions. Well, except
there's a small difference in the context, and build-clang.py doesn't
allow fuzz, so we manually edit the patch to remove that line from the
context.
--HG--
extra : rebase_source : cda077132ee499a8ffdc4c88a1160cfa5fd86a97
It now only does something trivial, which also happens to be a no-op
because it's the default. It does have a commented entry for possible
gtk+2 builds, but we're soon going to remove that possibility anyways in
bug 1278282.
--HG--
extra : rebase_source : 9ac927bb7bd8c057264c8f6f9ca5cbf79a839c4e
Now that build environment docker images have gtk+3 installed in
/usr/local, adjust mozconfigs to point pkg-config there, and remove
all the glue that was required to build using the tooltool package.
Also remove the --x-libraries=/usr/lib on 32-bits builds, which only
confuses the linker.
--HG--
extra : rebase_source : c7de7b3959a3c6b77ea202d9609c891b5b7ec442
Back when we started needing gtk+3 to build Firefox, we were using mock
to setup the build environment, and a tooltool package was the most
sensible way to handle this.
Fast forward to today, and we're close to moving the build environment
to Debian, which comes with gtk+3 packages. But in order to simplify
the various checks for the transition, it is desirable to stop using the
tooltool package. Which we can actually do in a reasonable way now that
we use docker images instead of mock, by building and installing gtk+3
in the build environment images.
So we modify the script that was producing the gtk+3 tooltool packages
such that it installs gtk+3 in the docker images, both 32 and 64 bits.
And invoke it when creating the desktop build environment docker images.
--HG--
extra : rebase_source : 75e987d6de7f3ae8a3d9b478fc173e191d28aace
ccache is not beneficial on taskcluster, don't try to use it when
sccache is not enabled for some reason.
--HG--
extra : rebase_source : a17fe88eb92072935cb86f9ada4205863cfc8f85
It now only does something trivial, which also happens to be a no-op
because it's the default. It does have a commented entry for possible
gtk+2 builds, but we're soon going to remove that possibility anyways in
bug 1278282.
--HG--
extra : rebase_source : 0de751e523ee002bbe6638d223eb384364edd22b
Now that build environment docker images have gtk+3 installed in
/usr/local, adjust mozconfigs to point pkg-config there, and remove
all the glue that was required to build using the tooltool package.
Also remove the --x-libraries=/usr/lib on 32-bits builds, which only
confuses the linker.
--HG--
extra : rebase_source : 22b1273ae4b78807b355d33ed5895bdfe83a141d
Back when we started needing gtk+3 to build Firefox, we were using mock
to setup the build environment, and a tooltool package was the most
sensible way to handle this.
Fast forward to today, and we're close to moving the build environment
to Debian, which comes with gtk+3 packages. But in order to simplify
the various checks for the transition, it is desirable to stop using the
tooltool package. Which we can actually do in a reasonable way now that
we use docker images instead of mock, by building and installing gtk+3
in the build environment images.
So we modify the script that was producing the gtk+3 tooltool packages
such that it installs gtk+3 in the docker images, both 32 and 64 bits.
And invoke it when creating the desktop build environment docker images.
--HG--
extra : rebase_source : fe18bfb2ec8db183c44838d5a7a0051322b2a9c0
At the same time, we make it actually do something on spidermonkey
builds. We also add an environment variable alternative, that we use
in mozconfig.stdcxx, allowing for mozconfig.no-compile to override it
and avoid configure failures on e.g. artifact builds.
--HG--
extra : rebase_source : b68d362025e0c99f9184a03391c652ec2c9357ad
Bug 1325632 added some facility to add target compiler flags. This
change extends it to add allow adding host compiler flags as well.
--HG--
extra : rebase_source : 424b405a1d8f9a4778ff75c3308c9622f050e194
We currently use a 32-bit Rust toolchain for win32 builds, but this can lead
to OOM situations. This patch makes win32 builds use a 64-bit Rust toolchain,
which requires a little bit of extra configuration because rustc needs to
be able to find a link.exe that produces 64-bit binaries for building
things like build scripts, which are host binaries.
We will now generate a batch file that sets LIB to the paths to 64-bit
libraries and invokes the x64-targeting link.exe, and add a section to the
.cargo/config file to instruct cargo to use that batch file as the linker
when producing 64-bit binaries.
MozReview-Commit-ID: 9vKBbm7Gvra
--HG--
extra : rebase_source : 366dd966cafe4f07b8e59fc170d2db2dada32627
Both the cc crate and the rust compiler may want to use "cc", which,
on automation, points to the system GCC compiler instead of ours.
As a workaround, we add a cc symbolic link in the GCC toolchain artifact
so that, as long as the GCC toolchain artifact's bin directory is in
$PATH early enough, it's picked over /usr/bin/cc.
--HG--
extra : rebase_source : 53cacf8a750539706a484218e168c8c9e0ba49a6
The "contract" for toolchains is that extracting foo.tar.xz creates a
directory named foo/. That is however not true for mingw32.tar.xz, which
extracts into gcc/, possibly overwriting files from the gcc.tar.xz
archive (which is also used for mingw builds, for the host part).
This is also not true for nsis.tar.xz, but it reportedly has problems
when it's not in the same directory as mingw32.
But mingw32 doesn't actually need to be mixed with gcc, so it's better
to separate them as they are supposed to be.
--HG--
extra : rebase_source : 30d90af64459bbb31bc076e48f3c661fa9cd4a79
We need MOZ_UI_LOCALE even when building the JS shell so
config/config.mk variable assignments don't run into issues. But it
doesn't make any sense to configure a UI locale for the JS shell. So
make --enable-ui-locale a normal `option`, but give it a `default`,
which is the value shell-only builds will always see.
--HG--
extra : amend_source : 047759dd6ec446d9d6f8f5992ed9cf6628ce859e
We're currently building GCC with the system binutils, which, at the
moment, is whatever version is available on the CentOS 6 build
environments. With the imminent switch to Debian 7, that will be a
different version.
It turns out the GCC configure script does enable some features
depending on the binutils it's built with. For the most notable
differences it makes when going from Centos 6 to Debian, it enables
.init_array/.fini_array depending on the binutils version, and enables
the use of CFI advances depending on gas and objdump respectively
supporting and displaying DW_CFA_advance_loc.
But we're already building a fixed version of binutils (which happens to
be more recent than the one in both CentOS 6 and Debian 7), and we're
using that version when using GCC to build, so we can just as much use
the version we built to build GCC.
In order to avoid any changes to the resulting builds, we explicitly
turn off .init_array/.fini_array (which currently happens implicitly
when building on CentOS 6). This will ensure that there is not other
change to the builds due to this binutils version bump
(.init_array/.fini_array being enabled shifts everything in the
binaries, so it makes the whole diff full of noise)
This has the virtue of not executing python three times during configure
just to read the same value of milestone.txt and munge it. We can also
remove milestone.py as a happy side effect, so all the milestone
computations can be done in init.configure.
lld is being too smart for its own good, and places non-relocatable data
right after the program headers, which prevents the program headers from
growing. But elfhack wasn't checking for that, so happily placed the
non-relocatable data at its non-relocated location, overwriting the last
item of the program headers.
--HG--
extra : rebase_source : 6f26d475f0a19d88ddf21399dbce8ceac62b492d
Bug 1385783 changed things such that the two elfhack sections are not
adjacent anymore. They can even be in different segments in some cases,
but the undo code doesn't know how to actually handle that case.
So for now, allow non adjacent sections, but still verify that they are
in the same segment.
--HG--
extra : rebase_source : da95ef7df19eeea8dfd07b24f22e7bee18939b69
Bug 1423803 was attempting to remove the fallible library but didn't do
so on Android because of this bug. We can now fully retire it.
--HG--
extra : rebase_source : de38872a08d24768eadfbe81652cfcd6aa7aa041
Bug 1256642 introduced magic at the emitter level to determine whether a
binary contains C++ sources and should be linked with the C compiler or
the C++ compiler.
Unfortunately, the Binary() moz.build template always adds C++ OS
libraries on Android (through STLPORT_LIBS), and C++ libraries on Linux
(stdc++compat).
The latter only ends up forcing every Binary() to be linked with the C++
linker, which is unfortunate, but doesn't cause much problems. The
former, however, involving OS libraries, the magic from bug 1256642
doesn't kick in, so we end up trying to link C++ OS libraries with the C
linker. Which ends up failing, because the libraries in STLPORT_LIBS
require -lm, which, while it's added by the C++ compiler when linking,
is not when the linkage is driven by the C compiler.
Because the fallible library, linked to all GeckoBinary()s is a C++
library, we still ended up linking with the C++ compiler on Android, so
this wasn't actually causing any problem... until I tried to remove that
fallible library in bug 1423803.
Anyways, the core problem is that moz.build evaluation is happening too
early to know whether any C++ sources are being linked together, so
there is no way the Binary() template can do the right thing. So this
change moves the logic to the emitter.
This also changes the type of STLPORT_LIBS to a list.
--HG--
extra : rebase_source : a70ddf7a132f94dc10e7e1db94ae80fb8d7a269f
upload-generated-sources tasks simply use `mach python` to run an in-tree
script, so they can save time by using a sparse profile.
MozReview-Commit-ID: LbXlibOP34W
--HG--
extra : rebase_source : c6b580b15671edeb700d191f651c79c6d6423394
Bump the minimum required Rust version now that 1.22.1
has been in stable release for more than two weeks.
Version 1.22.0 works fine everywhere but macOS 10.13,
but 1.22.1 was released the same day, so it's no harder
to upgrade to.
Also update the base-toolchain builds to ensure we
continue to build with this version.
MozReview-Commit-ID: GlRWUNE07G0
--HG--
extra : rebase_source : f37585db5633e6e64b02bc94c2516b5ab18c3e15
With all of our builds in Taskcluster now, we should never be uploading
symbols from build tasks. Unfortunately Windows builds were still doing so.
This patch removes MOZ_AUTOMATION_UPLOAD_SYMBOLS from all the in-tree
mozconfigs and a few other places so that it should always default off
(per moz-automation.mk). The rest of the uploadsymbols bits will be
removed once Thunderbird fixes their automation.
This patch was mostly autogenerated by running:
rg --files-with-matches UPLOAD_SYMBOLS browser/config/mozconfigs/ mobile/android/config/mozconfigs/ | xargs sed -ri '/.*UPLOAD_SYMBOLS.*/d'
sed -ri '/.*UPLOAD_SYMBOLS.*/d' build/unix/mozconfig.linux build/mozconfig.win-common build/macosx/local-mozconfig.common build/mozconfig.automation
Then mobile/android/config/mozconfigs/common and
taskcluster/scripts/builder/build-linux.sh were hand-edited.
MozReview-Commit-ID: Cy8kSEodSg4
--HG--
extra : rebase_source : 01caf1651b4eb428313e1f371aa585f8f34c4151
The upload-symbols task simply runs an in-tree Python script with
`mach python` so using a sparse profile will make this a bit faster.
MozReview-Commit-ID: 5HzwMf1FZLU
--HG--
extra : rebase_source : 74046b7917ee2e2ea7be0ec24f777f5fe819ef58
Will also address Bug 1377553 and part of Bug 1419607
MozReview-Commit-ID: AUCqBxEGpAl
--HG--
extra : rebase_source : f7582d7089f0f4582a02aeaef090dc0701df994d
With Gradle integration centralized in gradle.configure, changing
these integration points will need to trigger the android-* tasks.
MozReview-Commit-ID: DuOuW1RIgCh
--HG--
extra : rebase_source : a3f0a76b1ae6b3cd952271782f9d0c2463b704e0
With Gradle integration centralized in gradle.configure, changing
these integration points will need to trigger the android-* tasks.
MozReview-Commit-ID: DuOuW1RIgCh
--HG--
extra : rebase_source : 9aecfab8a8ce41441fb4c25021b14263d9c115c2
The std::nothrow variant of operator new is effectively a fallible
operator new. It is used in third party code.
The duplication with our own fallible operator new is unfortunate, and
we can reduce it by making one an alias of the other.
We keep the fallible library as a dummy on Android because bug 1423802
induces some linking problems.
--HG--
extra : rebase_source : d7b915aaafde40057e87b7ad4bbd82d348e4f12d
The last use in gecko was removed in the previous change, and the only
use in comm-central should be trivial to remove. It's not worth the
extra complexity to keep this argument.
--HG--
extra : rebase_source : 8576316190bf58476b7eb262deae4c972ea3dc2f
This is a new module that will provide a place to store some common
abstractions around the 'blessings' module. The main entrypoint is:
from mozterm import Terminal
term = Terminal()
If blessings is available, this will return a blessings.Terminal()
object. If it isn't available, or something went wrong on import,
this will return a NullTerminal() object, which is a drop-in
replacement that does no formatting.
MozReview-Commit-ID: 6c63svm4tM5
--HG--
extra : rebase_source : 9ab221774d92a418d9b098d79bb2c88f75d937f8
This library will be used to create test COSE signatures for the new COSE add-on
signature verification implementation.
MozReview-Commit-ID: KshKHwusT5h
--HG--
extra : rebase_source : 22d65622a77afc93b756829c8ffb4f37101dad26
extra : histedit_source : 869b9b65bdf201a027914a8127d28e5e9baf4d33
--enable-ion was only used by --enable-simulator and related options, so
there wasn't much point in making two separate commits.
This translation is a little more verbose than the original
old-configure code, but I think it is more readable and easier to
follow. We also don't port over --enable-simulator=no, as there doesn't
seem to be much point in doing so.
This is an import of the change from https://github.com/mozsearch/mozsearch/pull/66
plus a correction in the README file. The change was reviewed in github.
MozReview-Commit-ID: A7gINlBubZ4
And statically link logalloc.
Statically linking is the default, except when building with
--enable-project=memory, allowing to use the generated libraries from
such builds with Firefox.
--HG--
extra : rebase_source : efe9edce8db6a6264703e0105c2192edc5ca8415
And statically link logalloc.
Statically linking is the default, except when building with
--enable-project=memory, allowing to use the generated libraries from
such builds with Firefox.
--HG--
extra : rebase_source : efe9edce8db6a6264703e0105c2192edc5ca8415
rustup installs rustc+cargo to ~/.cargo/bin by default, so make configure look
there to avoid the annoying case where someone installed rust and cargo
(possibly via `mach bootstrap`) but forgot to add ~/.cargo/bin to their PATH.
MozReview-Commit-ID: GZOcFdFmzA5
--HG--
extra : rebase_source : 9dae473b5804f096992cae7f90df4c87bb4e5af4
extra : source : 9324e5e56038a1e548b0fc4d94d9df445734ff1e
The first step of making --enable-jemalloc the default everywhere is to
at least allow to build with it everywhere. Which currently probably
fails on a few platforms, but they're not going to be fixed if they're
explicitly rejected at configure time.
--HG--
extra : rebase_source : f29383e2d73986f3e5b033ac82c0d520bacd4fa6
Hopefully, the bug we worked around by disabling jemalloc on 32-bit OSX
is gone. We're not shipping 32-bit binaries for OSX anyways.
--HG--
extra : rebase_source : 148a80a7ab006d3be81fb931cbbb4ad2c81690c3
The first step of making --enable-jemalloc the default everywhere is to
at least allow to build with it everywhere. Which currently probably
fails on a few platforms, but they're not going to be fixed if they're
explicitly rejected at configure time.
--HG--
extra : rebase_source : 0905861d5a2cc62f5b37c5ee811e56e1e063a133
Hopefully, the bug we worked around by disabling jemalloc on 32-bit OSX
is gone. We're not shipping 32-bit binaries for OSX anyways.
--HG--
extra : rebase_source : bfe765977dedf1949da4d5919032cadfb4675f1f
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
getTopActivity calls 'adb shell dumpsys window windows' which intermittently
times out. Instead of ending the test run when that happens, let's try
again, in hopes of recovering. If recovery fails and the browser is
subsequently found running, log an explanation before killing it.
We were adding c_compiler.flags and toolchain_flags to some paths
through this function, but not all. Not adding those flags caused this
function to detect the host's ld.gold instead of the target's ld.gold.
And that, in turn, caused linker errors when the host ld.gold couldn't
understand the target's object files.
MozReview-Commit-ID: vJzWagUGkL
This was mainly used to support Universal MacOS builds, which were
removed several months ago.
In theory, someone could be using this feature to build multiple
applications with one build system invocation. But given that client.mk
is no longer the preferred interface to the build system and multiple
applications can be built by running `mach build` with different
mozconfigs, I don't think support for this feature is worth keeping.
This commit removes support for MOZ_BUILD_PROJECTS and related
functionality from client.mk. Support for recognizing
MOZ_CURRENT_PROJECT in configure and mozconfig evaluation has also
been removed. This includes support for the ac_add_app_options
mozconfig function.
Good riddance.
MozReview-Commit-ID: 7xI2jYxDFFr
--HG--
extra : rebase_source : 91068f3b8ae32fbcda4defb5d4bb086a04387598
Csoregi Natalia
Ryan VanderMeulen
Mike Hommey
shindli
Ralph Giles
Margareta Eliza Balazs
Nick Alexander
Dustin J. Mitchell
Dorel Luca
Narcis Beleuzu
Chris Manchester
Gregory Szorc
Tom Prince
Matías Zúñiga
Andi-Bogdan Postelnicu
Emilio Cobos Álvarez
Jean-Luc Bonnafoux
Andreea Pavel
Ted Mielczarek
Zibi Braniecki
Makoto Kato
Ciure Andrei
Coroiu Cristina
Tiberius Oros
Chris Cooper
David Major
Nathan Froyd
Nathan Froyd
Aki Sasaki
Cosmin Sabou
Sylvestre Ledru
Tom Ritter
Bogdan Tara
Julian Hector
Tim Taubert
Gurzau Raul
Andrew Halberstadt
David Keeler
Marco Castelluccio
Noemi Erli
Edouard Oger
Kartikaya Gupta
Nika Layzell
Christian Holler
Bob Owen
Bill McCloskey
Alfredo.Yang
Brindusan Cristian
André Bargull
arthur.iakab
Chris Peterson
John Lin
Robert Helmer
Randall Barker
Sebastian Hengst
Masatoshi Kimura
J.C. Jones
Geoff Brown
Petr Sumbera