This incorporates some fixes for ccache, icecream, and a better display
output (decreasing count instead of an increasing count). It may also
let us experiment with incremental rust support, though I think that
feature still needs some more work.
MozReview-Commit-ID: 7zPGiL9Ob6N
Differential Revision: https://phabricator.services.mozilla.com/D7152
--HG--
extra : moz-landing-system : lando
This extracts the current logic for finding nodejs into its own module in mozbuild. Configure and ESLint then use it.
For ESLint, this will change the first location it looks for nodejs to be the .mozbuild directory.
Differential Revision: https://phabricator.services.mozilla.com/D6430
--HG--
extra : moz-landing-system : lando
Some build flags are being passed by the build system: they're passed in a text
file called extra-bindgen-flags.in that's filled at configure time.
Other flags have to be inferred from the current target/host combination, in
Cranelift's build script directly. This is mostly cargo-culted from the
ServoBindings.toml file, and should probably be merged in the build system at
some point.
Some Windows-specific adjustments were needed to provide access to libclang for
bindgen support, by adding clang-cl to the plain Spidermonkey Windows builds.
--HG--
extra : rebase_source : 0bda40b1d1eb38c2657593f094c951013711d00a
extra : histedit_source : aad930a5f9099e299d385ae4de2deb81aed9b6d5
It's nicer to have all that logic in one place, and to be able to common
up the Unix-y flags setting. The Makefile constructs in string values
is gross, but it's no worse than we had before.
Now that we ship builds using clang on all platforms, pick it during
configure. It is still possible to opt-in to building other compilers by
setting CC/CXX (or even only CC) to the desired compiler.
Depends on D5829
Differential Revision: https://phabricator.services.mozilla.com/D5637
--HG--
extra : moz-landing-system : lando
Before this change, we'd derive a host compiler and handle things as if
HOST_CC/HOST_CXX had been passed. With this change, we change the list
of compilers that are tested with check_prog instead.
Depends on D5828
Differential Revision: https://phabricator.services.mozilla.com/D5829
--HG--
extra : moz-landing-system : lando
Currently, when building for Android x86-64 on Linux x86-64, we drop the
'--target' flag, which causes the build to fail. This patch adds a check
for OS mismatch, so we keep the '--target' flag in this situation.
Differential Revision: https://phabricator.services.mozilla.com/D4483
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.
Last attempt, a few years ago, blatantly failed because nautilus (the
GNOME file manager) can't start PIE executables, which look like shared
libraries, and that it thus considers not being executables.
Downstreams don't actually have the problem, because users won't be
launching Firefox from a file manager, but for mozilla.org builds, it is
a problem because users would download, then extract, and then likely
try to run the Firefox executable from a file manager.
So for mozilla.org builds, we still need to find a way around the
nautilus problem.
A .desktop file could be a solution, but .desktop files have not
actually been designed for this use case, which leads to:
- having to use an awful one-liner shell wrapper to derive the path
to the executable from that of the .desktop file,
- not even being able to associate an icon,
- the .desktop file not being copiable to a location where .desktop
files would normally go, because it would then fail to find the
executable.
Another possibility is to go back to using a shell wrapper, but that's
not entirely appealing.
What we chose here is similar, where we have a small `firefox` wrapper
that launches the real `firefox-bin` (which is still leftover from those
old times where we had a shell wrapper, for reasons).
The small `firefox` wrapper is a minimalist C executable that just
finds the path to the `firefox-bin` executable and executes it with the
same args it was called with. The wrapper is only enabled when the
MOZ_NO_PIE_COMPAT environment variable is set, which we only take into
account on Linux. The variable is only really meant to be used for
mozilla.org builds, for the nautilus problem. Downstreams will just pick
the default, which is changed to build PIE.
On other platforms, PIE was already enabled by default, so we just
remove the --enable-pie configure flag.
Differential Revision: https://phabricator.services.mozilla.com/D5109
As described in c2b5cf7bde83, it is still preferable to build with BFD
ld when doing clang LTO, and one of the reasons we defaulted to lld in
the first place is that we didn't have the LLVM gold plugin on
automation, which, as of bug 1488307, we now have.
Differential Revision: https://phabricator.services.mozilla.com/D4987
At least, when that combination doesn't work. This requires passing the
LTO flags to the compiler invocations for the test, which in turn
requires actually calling the linker directly on Windows, instead of
directly through the compiler, as when actually building.
Differential Revision: https://phabricator.services.mozilla.com/D4739
--HG--
extra : moz-landing-system : lando
This setup seems to work well enough to enable me to link
HOST_SIMPLE_PROGRAMS with an AArch64-cross setup. Necessary library
paths are passed to the linker via -LIBPATH and HOST_LDFLAGS rather than
letting MSVC fish them out of the environment. The change to
HOST_SIMPLE_PROGRAMS to pass HOST_LDFLAGS was necessary for this to
work, in addition to the HOST_LINKER changes.
-Wtautological-overlap-compare is an opt-in warning added in clang 3.5. It warns about overlapping comparisons that are always true or false, such as:
if (x > 4 || x < 10) {} // warning! always true
int b = x < 2 && x > 5; // warning! always false
return x > 4 || x < 10; // warning! always true
https://clang.llvm.org/docs/DiagnosticsReference.html#wtautological-overlap-compare
There are currently no -Wtautological-overlap-compare warnings in mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D3477
--HG--
extra : rebase_source : e6aa211a338633e5fb7507b3a8f341709d72d6c9
This opt-in warning catches bugs where a constructor modifies a constructor parameter that shadows member variable name. The code probably intended to change the member variable value, not the paramter. There are currently no -Wshadow-field-in-constructor warnings in mozilla-central.
https://clang.llvm.org/docs/DiagnosticsReference.html#wshadow-field-in-constructor-modified
Differential Revision: https://phabricator.services.mozilla.com/D3822
--HG--
extra : rebase_source : 604ff90e036d536955db41351ee9ee97e8424d92
extra : intermediate-source : 712f538afc160f4efae2383130727edbd1dd70f6
extra : source : 300fff9a58515c7cac0647afc9ccc0e69bc8c5cb
-Wfloat-overflow-conversion detects when a constant floating point value is converted to an integer type and will overflow the target type.
https://clang.llvm.org/docs/DiagnosticsReference.html#wfloat-overflow-conversion
-Wfloat-zero-conversion detects when a non-zero floating point value is converted to a zero integer value.
https://clang.llvm.org/docs/DiagnosticsReference.html#wfloat-zero-conversion
There are currently no -Wfloat-overlap-conversion warnings in mozilla-central. There is one -Wfloat-zero-conversion warning in a webrtc test. It doesn't block enabling this check because the webrtc tests are not compiled with warnings-as-errors.
media/webrtc/trunk/webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller_unittest.cc:255:54 [-Wfloat-zero-conversion] implicit conversion from 'const float' to 'int' changes non-zero value from 0.045000002 to 0
We can't enable all -Wfloat-conversion warnings (for any implicit conversion of a floating-point number into an integer) because there are currently over 1400 warnings. I spot checked a few of these -Wfloat-conversion warnings. I didn't find any obvious bugs, but there is some suspicious code, such as implicit conversions of floats to bools.
Differential Revision: https://phabricator.services.mozilla.com/D3476
--HG--
extra : rebase_source : 589be9e593749c7000b1f89ca155e4f95a487f8f
Warn about C++ constructs whose meaning change in C++2a.
https://clang.llvm.org/docs/DiagnosticsReference.html#wc-2a-compat
So far the only -Wc++2a-compat check that I know of is for valid pre-C++2a code that inadvertently parses as C++2a's new <=> "spaceship" comparison operator. `f<&A::operator<=>();` is an example of a warning reported for a real project on GitHub. That code can be rewritten as `f< &operator<= >();`.
There are currently no -Wc++2a-compat warnings in mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D3478
--HG--
extra : rebase_source : 4ec8147ad3fe2d1ef7c543d100c660a000385786
Our version check is removed as well, as the current required rustc version for
Firefox includes all features required to build with tup.
Differential Revision: https://phabricator.services.mozilla.com/D3847
--HG--
extra : moz-landing-system : lando
In order to support operator==() for tagged enum, we have to bump the version to
0.6.2.
Differential Revision: https://phabricator.services.mozilla.com/D3932
--HG--
extra : moz-landing-system : lando
We're currently using NDK r15c, which is rather old, and happens to come
with a buggy gold linker. Let's use a more recent NDK, with a fixed
linker.
Unfortunately, we're currently at NDK API level 9, which the newer NDK
doesn't provide for x86 anymore. But that corresponds to Gingerbread
(2.3), which we've long stopped supporting. On the SDK side, we already
dropped support of versions before Jelly Bean, so we can do the same on
the NDK side. That corresponds to API level 16. So let's just use that
as a baseline.
Another change in the newer NDK is that the target-name changed from
i386-linux-android to i686-linux-android, so adjust for that in the
android x86 mozconfigs.
We're currently using NDK r15c, which is rather old, and happens to come
with a buggy gold linker. Let's use a more recent NDK, with a fixed
linker.
Unfortunately, we're currently at NDK API level 9, which the newer NDK
doesn't provide for x86 anymore. But that corresponds to Gingerbread
(2.3), which we've long stopped supporting. On the SDK side, we already
dropped support of versions before Jelly Bean, so we can do the same on
the NDK side. That corresponds to API level 16. So let's just use that
as a baseline.
Another change in the newer NDK is that the target-name changed from
i386-linux-android to i686-linux-android, so adjust for that in the
android x86 mozconfigs.
We only enable libstdc++ compat on Android for the host parts, and
in practice, the target part has it not enabled at the moment because
libstdc++ can't be found. But making the clang toolchain capable of
building for x86 changes the deal for Android x86.
We need to add mappings for target.cpu to MSVC's arm64 name for
determining various paths, and we need to add an extra case to
get_vc_paths so the compiler can find all the necessary DLLs.
This patch adds JaCoCo as a dependency for the geckoview androidTest configurations, as well as
the `mach android archive-geckoview-coverage-artifacts` command, and the `--enable-java-coverage`
mozconfig flag.
MozReview-Commit-ID: 36jNAzK44g3
--HG--
extra : rebase_source : 9edc37913a3929ad045270c601c77791d122e363
JS, at least, doesn't need bindgen at this point. If JS does start
requiring bindgen under certain build configurations, we'll have to
figure out what to do about the bindgen dependency at that point:
require bindgen always, or just require bindgen for the
configuration(s).
Currently, --enable-lto just implies --enable-linker=lld, which
essentially only works on Linux, and assumes one can't do lto with
anything other than lld. Which is not true. As a matter of fact, even
ld.bfd can do lto, as long as the gold plugin for llvm is available,
or when doing lto with GCC instead of clang.
Anyways, to allow more lto setups, we adapt the --enable-linker setup
to:
- work on macOS, which it currently doesn't, and add support for the mac
linker (ld64), which, unfortunately, doesn't have a clean way to be
detected, so work around that.
- default to lld if lto is enable, no linker was explicitly given, the
compiler is clang *and* the build target is not macOS.
--HG--
extra : rebase_source : 1dab2ad6230d18e7f4285943e76352e23b987d4e
Because we have no linking configure test in python configure (yet), we
just make old-configure tests use LINKER_LDFLAGS, and make those flags
added to LDFLAGS by old-configure at the same time.
--HG--
extra : rebase_source : 80ab7c5021c7ddd1b53d58ef76cd4372a524d3cb
The intent is for the build system to soon require Node.js to build
Firefox. But we aren't ready to make Node.js a build requirement
just yet.
The goal of this commit is to implement configure detection for
Node.js so that we can a) work out detection bugs b) give people a
means to validate system compatibility *before* we throw the switch to
require Node.js.
This commit introduces configure logic for finding a Node.js
executable, resolving its version, and validating its suitability.
By default, if Node.js cannot be found or there is an error resolving
its version, we print some warning messages and move on.
If --enable-nodejs is used (not the default), errors are raised
if Node.js cannot be found or its version isn't suitable.
Once we require Node.js, the added code can likely be simplified.
When writing the code, I went out of my way to make failures as
non-fatal as possible. e.g. normally we'd say that failures to run
`node --version` would be fatal. I'm purposefully trying to not have
this configure check break anyone's environment, even if failure
occurs. Again, the goal is to introduce the configure checks first
in a non-fatal way such that we can debug failures so the flag day
transition is simpler.
Differential Revision: https://phabricator.services.mozilla.com/D1818
--HG--
extra : moz-landing-system : lando
We're well overdue for an upgrade of the rust compiler requirements.
Now that we're building with 1.28 (albeit a beta, due to be bumped when
it's released), we can bump the requirement away from 1.24 which is now
old. 1.27 is too new, though, so settle for the older 1.26.
--HG--
extra : rebase_source : a17aa496bf3d4af4d1349d69a637c686c6817d0f
When I originally implemented bug 1458161, this is how it was done, but
it was suggested to use a configure-time check. This turned out to not
be great, because the rust compiler changes regularly, and we don't run
the configure tests when the version changes. When people upgraded their
rust compiler to 1.27, the code subsequently failed to build because the
features were still set for the previous version they had installed.
--HG--
extra : rebase_source : 1b5f7a02ad8495d68cd29289f7beea59b8912183
We're well overdue for an upgrade of the rust compiler requirements.
Now that we're building with 1.28 (albeit a beta, due to be bumped when
it's released), we can bump the requirement away from 1.24 which is now
old. 1.27 is too new, though, so settle for the older 1.26.
--HG--
extra : rebase_source : c788ef4f7da9949b81df2f0577af6f6039ea63d8
When we're running using pipenv, we have more than one virtual environment. This means the current check to see if python matches the initial virtual environment gives a false positive when we're in a secondary virtual environment. This patch changes the condition to check if the current python path exists within the virtual environments root directory.
MozReview-Commit-ID: AAONwLWsigL
--HG--
extra : rebase_source : c0ac94448ee4545417b5116e58b51c6187cdb175
We used to do that before bug 1455767. Taking a step back, what we want
(and what this change implements) is to:
- allow to specify a linker to use explicitly
- check that using the corresponding linker flags makes us use that
linker
- if no linker is specified, and developer options are enabled, we want
to try to use gold if it's available, otherwise, we want to detect
what kind of linker the default linker is
- if --disable-gold is explicitly given, we don't want to automatically
use it.
--HG--
extra : rebase_source : 8d89c54bd5e555984d815beb8fdd3f5f75dae31e
We used to do that before bug 1455767. Taking a step back, what we want
(and what this change implements) is to:
- allow to specify a linker to use explicitly
- check that using the corresponding linker flags makes us use that
linker
- if no linker is specified, and developer options are enabled, we want
to try to use gold if it's available, otherwise, we want to detect
what kind of linker the default linker is
--HG--
extra : rebase_source : 655089f29c6403f6c31a977dcf5c6fd1e9941121
--enable-release not being passed means developer options are enabled,
which is generally speaking not desirable for builds meant to be
shipped. This is somewhat alleviated for Firefox by MOZILLA_OFFICIAL
implying --enable-release (as well as MOZ_AUTOMATION), but that doesn't
apply to e.g. standalone js builds (even some of the standalone js jobs
on our automation don't set MOZ_AUTOMATION for some reason).
A reasonable thing to do is just to default builds for release/beta
milestones to --enable-release, but still allow --disable-release
to enable the developer options.
--HG--
extra : rebase_source : 770d51b10a9cd17c63972435bb61eed10345ea71
Can be used:
ac_add_options --enable-linker=lld-7
or
ac_add_options --enable-linker=lld
MozReview-Commit-ID: GfDevGeooU4
--HG--
extra : rebase_source : ee2aad5f8f721a6fe5840affde6b29a3b940fb91
This option does nothing if it's provided, and things will probably
break in some most peculiar manner if somebody uses --without-pthreads.
Given that neither outcome is useful, we should remove the option.
OOM rust crashes are currently not identified as such in crash reports
because rust libstd handles the OOMs and panics itself.
There are unstable ways to hook into this, which unfortunately are under
active changes in rust 1.27, but we're currently on 1.24 and 1.27 is not
released yet. The APIs didn't change between 1.24 and 1.26, so it's
fine-ish to use them as long as we limit their use to those versions.
As long as the Firefox versions we ship (as opposed to downstream) use
the "right" version of rust, we're good to go.
The APIs are in their phase of stabilization, so there shouldn't be too
many variants of the code to support.
--HG--
extra : rebase_source : 08a85aa102b24380b1f6764effffcc909ef3191b
We previously did not require Python 3.5+ everywhere because we failed
to detect Python 3.5 on Windows in CI. That's because CI isn't using
start-shell.bat and it hasn't yet updated PATH to include
%MOZILLABUILD%\python3.
We shouldn't need to teach CI to have PATH contain everything in
MozillaBuild. This commit teaches moz.configure to automatically use
MozillaBuild's Python 3 if we're running in MozillaBuild.
Since we can now detect Python 3 everywhere in CI, we make Python 3.5+
required on all build configurations.
MozReview-Commit-ID: BwgWGeYMyPM
--HG--
extra : rebase_source : b52f604b01c73b0493b142f3f71aa26c99a42b91
But only if we are:
a) not running in CI
b) running in CI on Linux
We will ideally make the requirement global. But Python 3.5 is not
yet available in CI on macOS. And we're not finding the MozillaBuild
copy in configure.
This was previously announced in November at
https://groups.google.com/d/msg/mozilla.dev.platform/rJrPh1QYXrQ/hqRrQsJ_BgAJ.
MozReview-Commit-ID: IyPCAcL3gop
--HG--
extra : rebase_source : f9e3db043a1ce9c1a903c943663f22245febf101
Nathan Froyd
Ciure Andrei
Mike Shal
Chris Manchester
Mark Banner
Thomas P.
Andreea Pavel
Mike Hommey
Benjamin Bouvier
Masatoshi Kimura
Dorel Luca
shindli
Robert Bartlensky
Jim Chen
Ted Mielczarek
Margareta Eliza Balazs
Andreas Tolfsen
Robert Longson
Landry Breuil
Chris Peterson
Boris Chiou
David Major
Emilio Cobos Álvarez
Dan Mosedale
Cosmin Sabou
arthur.iakab
Dan Mosedale
Bogdan Tara
Noemi Erli
Tudor-Gabriel Vîjială
Nika Layzell
Ivan Pozdeev
Jacek Caban
Gregory Szorc
Xidorn Quan
Dave Hunt
Marco Castelluccio
Gurzau Raul
Tom Ritter
Miko Mynttinen
Jonathan Watt
Christian Holler
Sylvestre Ledru
Jan Beich
Jeff Gilbert
Carl Corcoran