The base bootstrap class has code to conditionally upgrade Mercurial
depending on its version. It is kinda broken. This commit overrides
that code in the MozillaBuild bootstrapper to always run `pip`, which
will ensure the latest stable Mercurial release is installed.
MozReview-Commit-ID: 2O1Ff7dAp4o
--HG--
extra : rebase_source : 98cba0abbebf13e8fe93673d5b46eb16e6a3c147
Previously, `mach bootstrap` would unconditionally prompt to help
configure Mercurial in most scenarios. I agree with Ehsan's observation
in a mailing list post that this behavior doesn't make sense when
running from a Git checkout, as the user probably doesn't care about
Mercurial if they are using Git.
This change doesn't completely ignore Mercurial for Git users. For
example, we still unconditionally run code that verifies that Mercurial
is installed and reasonably up to date. Changing this would be a bit
of work. But even if we wanted to change it, git-cinnabar users
would benefit from having a modern Mercurial installed. So it isn't
straightforward for Git users to ignore Mercurial completely.
MozReview-Commit-ID: 8ncHRgCsjz
--HG--
extra : rebase_source : 7945e3bf3d5283105bac517885f794fc5d7bba6d
Doing something like "not foo" when foo is a @depends function is never
going to do what the user expects, while not necessarily leading to an
error (like, when used in set_config).
It is better to have an error in those cases where it's expected not to
work, at the expense of making templates a little more verbose, rather
than silently do something the user is not expecting.
--HG--
extra : rebase_source : 87ba80eccc5606322f6dd185d5cb5fc88471e51b
Artifact builds were relying on disabling Rust source file inclusion.
The RustLibrary mozbuild class wants to know cargo's output directory
when initializing itself, but when no compile environment is available
rust.configure isn't included and the corresponding config keys
aren't available.
Skip inializing the dependent fields in that case. Since the artifact
build never tries to compile any of the rust libraries, leaving
these properties undefined works ok.
MozReview-Commit-ID: 8IzTsweSygn
--HG--
extra : rebase_source : a59fc01483fbc85766ff4445c5db7ddb1e49b87c
mozconfig_loader is invoked with /bin/sh, which may not be bash. We could
force mozconfigs to be run with bash instead, but that might be disruptive
for existing mozconfigs, and the sole bashism used in mozconfig_loader is
rather straightforward to workaround by namespacing the variables.
Fixes a 403 error running `./mach bootstrap` with stylo enabled.
Bug 1359968 updated the tooltool manifests to point to a
publicly-available clang package. Update the macOS hash
used by mozboot to install the same package for local
use by developers who need rust-bindgen.
MozReview-Commit-ID: FtkATaLwc7n
--HG--
extra : rebase_source : 61390c729e694589b0351026aac0263440a9a3c5
The Python print() function's does not take a format string, so the extraneous %s here inadvertently prints "Downloading clang package from %s https://..." instead of "Downloading clang package from https://...".
MozReview-Commit-ID: 5Is5TK3X34e
--HG--
extra : rebase_source : 02e625fbdaab536d1a787c33edd6dfda9c1039c6
We've traditionally had per-directory 'update' scripts for
third-party media codec implementations. Instead, leverage
the new 'mach vendor' command to centralize the import and
build file generation, placing the upstream source in
third_party/aom.
Note this includes another copy of gtest and other dependencies
which we don't use, but they're required by the upstream build
process we use to generate our own build description, so I've
left them in for now.
MozReview-Commit-ID: CnWcSwvQZEh
--HG--
extra : rebase_source : 28172a41332e920c9ea4a475a6990d43ebf8185f
Add AArch64/ARM64 support to the script that produces android version
codes. Use the same scheme for AArch64 as x86, since the two
architectures don't overlap, and AArch64 should override ARM just like
x86 should override ARM.
For Stylo development, LLVM packages are required due to Stylo's
extensive use of bindgen--generating Rust bindings to Gecko's C++ code.
While people can install LLVM via their system package manager, we've
opted to download the LLVM packages used on Mozilla infrastructure for
building Gecko. Using Mozilla's packages for LLVM ensures that they
work, and also makes it easier/trivial to integrate support for other
things (e.g. Mozilla's static checkers) into `mach bootstrap`.
The way it works today, compiler warnings are logged to build output
twice. The compiler's raw output is logged. Then, if mach's compiler
warning parser detects a warning, a structured log message with info
about that warning is printed as well. Because of the order in which
callbacks fire, mach's warning message is delivered to the logger
first. So build output looks something like:
0:04.63 Warning: -Wsign-compare in /home/gps/src/firefox/security/nss/lib/dev/ckhelper.c: comparison of integers of different signs: 'CK_ULONG' (aka 'unsigned long') and 'int'
0:04.63 /home/gps/src/firefox/security/nss/lib/dev/ckhelper.c:135:45: warning: comparison of integers of different signs: 'CK_ULONG' (aka 'unsigned long') and 'int' [-Wsign-compare]
0:04.63 (obj_template[i].ulValueLen == -1)) {
0:04.63 ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~
That first line is our structured message formatted to plain text.
Subsequent lines are Clang.
The output here is redundant. But having the structured compiler warning
in the JSON logs is nice so downstream systems don't have to reinvent
the parsing wheel.
Also today, at the end of a clobber build we print a count of the
total number of compiler warnings.
Compiler warnings represent potential bugs. So we want to encourage
people to look at them. However, with build system output often spanning
several hundred lines and compiler warnings scattered in no
deterministic order because build system execution is non-deterministic,
it is easy to lose sight of compiler warnings as they go by in build
output. And, it can be difficult to find a warning in files you care
about because you don't know where in the log to look for that file.
This commit attempts to improve the visibility of compiler warnings
by printing a sorted list of warnings at the end of the build. The list
of warnings it prints are only those seen during the current build
operation. We /could/ print a list of all warnings in the persisted
database. But I think this would be annoying, particularly for
incremental or partial builds.
The structured log message previously emitted at compiler invocation
time has been removed. So now the build backend output doesn't have a
redundant "Warning: " line summarizing the warning next to the compiler
output itself. This is less confusing.
That structured log message has been reborn at the end of the build
and reformatted slightly. If there are any consumers assuming that the
log entry near this structured message is compiler output itself,
they will break. I don't think any such consumers exist. It is also
possible the structured log may not contain warning messages if a
process exit occurs. I'm fine with this: if the `mach` process dies,
we have bigger problems to worry about.
The new output looks something like this:
18:07.97 warning: gfx/angle/src/compiler/translator/util.cpp:216:15 [-Wimplicit-fallthrough] unannotated fall-through between switch labels
18:07.97 warning: gfx/angle/src/compiler/translator/util.cpp:225:15 [-Wimplicit-fallthrough] unannotated fall-through between switch labels
18:07.97 warning: gfx/angle/src/compiler/translator/util.cpp:234:15 [-Wimplicit-fallthrough] unannotated fall-through between switch labels
18:07.97 warning: gfx/cairo/libpixman/src/pixman-bits-image.c:268:32 [-Wshift-negative-value] shifting a negative signed value is undefined
18:07.97 warning: gfx/cairo/libpixman/src/pixman-linear-gradient.c:395:6 [-Wunreachable-code] code will never be executed
18:07.97 warning: gfx/cairo/libpixman/src/pixman-x86.c:80:5 [-Wexpansion-to-defined] macro expansion producing 'defined' has undefined behavior
Note the sorting of files, including by line number and column. If we
wanted to, we could even print that line. But that's for another day
(especially since compilers themselves tend to do this already).
This change has the potential to annoy people. That's because instead
of the parsed warning summary lines being spread out over the build
(where they tend not to be noticed), they will be lumped at the end of
the build log, which people do tend to notice. In my build, I have
~363 warnings/lines. Some could perceive this as excessive and
redundant. But the recourse for this is simple: eliminate compiler
warnings. My hope is that by having the compiler warnings exposed
clearly at the end of the build log that people will notice them
and will take action to eliminate them. Sunlight is a disinfectant.
MozReview-Commit-ID: 9VHXsPhAYmr
--HG--
extra : rebase_source : 6a2da05f794a54ea54a48167a36d130dfbf34e59
Currently, the build monitor has a single compiler warnings database
that unions warnings from previous runs with warnings from the current
invocation. I want to introduce functionality that treats warnings
seen during the current invocation differently from "all warnings."
To facilitate this, this commit introduces a 2nd, non-persisted
warnings database to record warnings just for the current invocation.
MozReview-Commit-ID: FIY0GiarDmr
--HG--
extra : rebase_source : b2002e1c248ea65b2c0ee45a78b1e74d61a26f3c
Currently, the WarningsCollector (which parses warnings from line inputs)
accepts a WarningsDatabase (an object representing a collection of
warnings) and populates that instance as a new warning is parsed. In
an upcoming commit I want to introduce a 2nd WarningsDatabase.
Rather that add it to WarningsCollector, I figure it will be easier
to decouple WarningsDatabase from WarningsCollector.
This commit refactors WarningsCollector to call a callback when a
warning is parsed. This allows consumers to do anything they want
with a warning, including potentially write it to multiple databases.
MozReview-Commit-ID: 7Z9x4FMwyof
--HG--
extra : rebase_source : b4844b5c2b1926840d37e46ead38c8c358762ba8
mozharness is currently making a manual `make -k` invocation. We don't
want automation calling `make` directly. So teach `mach build` to
accept a --keep-going argument that results in `make -k`.
MozReview-Commit-ID: H3lJ4r8S4vj
--HG--
extra : rebase_source : 9feb7bcaeb855254c53c5fa9d49177c5133f2773
This patch adds a copy of vswhere.exe to build/win32, downloaded from the
current latest release (1.0.62):
https://github.com/Microsoft/vswhere/releases/download/1.0.62/vswhere.exe
It changes toolchain.configure to invoke vswhere.exe instead of reading
the registry, since that no longer works for VS2017 (but vswhere can locate
VS2015). It also removes a layer of complexity in that code by dropping
support for non-64-bit host systems, since we don't really support building
on 32-bit Windows anymore anyway.
There's a little bit of fixup in windows.configure where some LIB paths
have changed in 2017.
MozReview-Commit-ID: 5XLWjidS6W4
--HG--
extra : rebase_source : 90f79b6f4a2d8d925dd20eb0bf6ab96262c227d5
rustc generates .lib files for its libraries when compiling for Windows
(even using MinGW on Linux). But MinGW expects .a files. So we add in
rust-specific prefix and suffixes so MinGW builds can find the libs that
rustc generates. (And the RUST_LIB- variables default to the same vales
as the LIB_ variables otherwise.)
MozReview-Commit-ID: ClsA0YuJaxh
--HG--
extra : rebase_source : 7b46460c94ceb34b7a5a302ce91d3f1dca600041
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
There can be cases where there is simply nothing to download, especially
with the --for-job argument. So we just stop erroring out when nothing
was downloaded.
However, if the user explicitly requested a particular file(s) via the
command line and there is nothing to download, we still emit an error
code.
--HG--
extra : rebase_source : 143c15c9711bbfbbfdc110da14f3738132d53ed4
This patch does a few things:
a) Adds the resources location from the .app directory to the read whitelist
b) When it's a non-packaged build, mach run (and various mach tests) set an environment variable for the repo location which we allow reads from.
r=haik,froydnj
MozReview-Commit-ID: KNvAoUs5Ati
--HG--
extra : rebase_source : 81ba8bfee0ca96979cf8e30d75cdd47f06bc10ea
This patch does a few things:
a) Adds the resources location from the .app directory to the read whitelist
b) When it's a non-packaged build, mach run (and various mach tests) set an environment variable for the repo location which we allow reads from.
r=haik,froydnj
MozReview-Commit-ID: KNvAoUs5Ati
--HG--
extra : rebase_source : f637acff32fc8582732de932503dd696abc57877
Mike Hommey
Gregory Szorc
Nick Alexander
Jan Beich
Ralph Giles
Wes Kocher
Carsten "Tomcat" Book
Petr Sumbera
Chris Manchester
Chris Peterson
Jim Chen
Nathan Froyd
Shing Lyu
Ted Mielczarek
J. Ryan Stinnett
Tom Ritter
Luis de Bethencourt
Mark Banner
Sebastian Hengst
Cameron McCormack
Alex Gaynor