Bug 1690930 added sysroots that can be bootstrapped. With this change,
we allow --enable-bootstrap=install to pull the right sysroot for the
configured target, and --enable-bootstrap to update it if it was already
there.
Differential Revision: https://phabricator.services.mozilla.com/D104797
The code in MozbuildObject.get_mozconfig_and_target relies on the
configure sandbox to find mozconfig (and target). With
--enable-bootstrap, configure itself ends up calling into taskgraph code
that, eventually ends in in MozbuildObject.get_mozconfig_and_target,
which, because it currently logs to the same place, has at least the
following two effects:
- MOZ_CONFIGURE_TRACE logging breaks. I'm not sure exactly why, but the
log level is lost.
- the output from the configure code that runs for
MozbuildObject.get_mozconfig_and_target ends up mixed with the output
from configure itself, and it appears to the user as if things happened
twice (which it did, actually, but that's not something that should be
shown to the user).
So, we redirect to a separate logger.
Differential Revision: https://phabricator.services.mozilla.com/D104776
This lets Treeherder pick up the line as failure line and show it to Try users
and code sheriffs.
Rule used: "^[A-Za-z.]+Error: "
It also adds an instruction how to fix the reported issue.
Differential Revision: https://phabricator.services.mozilla.com/D104452
Other platforms are going to need more annotations, so this allows us to
update one line while rolling out the feature, rather than updating a
bunch of test expectations. Also should be clearer.
Let me know if there are better ways to do this.
Differential Revision: https://phabricator.services.mozilla.com/D104102
Other platforms are going to need more annotations, so this allows us to
update one line while rolling out the feature, rather than updating a
bunch of test expectations. Also should be clearer.
Let me know if there are better ways to do this.
Differential Revision: https://phabricator.services.mozilla.com/D104102
It's already part of Firefox, and makes the gtest initialization print
an error message because the one already in Firefox can't be
overwritten.
Differential Revision: https://phabricator.services.mozilla.com/D103475
Bug 1553230 made configure automatically get toolchain artifacts in some
cases. The artifacts for clang-cl builds are clang.tar.zst, and extract to
clang/. Configure derives the task name from that knowledge, and fails
to find clang-cl tasks because of that.
For consistency, these tasks should be called clang. They are clang
builds anyways, and like any other clang builds, they also contain
clang-cl.
Differential Revision: https://phabricator.services.mozilla.com/D103150
This allows to filter chrome manifest registration by the current
background task(s, in the future). Filtration behaves just like
filtering by "application":
* filter with `backgroundtask=` means disable for all background
tasks, since no background task will match ""
* filter with `backgroundtask!=` means enable for all background task,
since every background task will not match ""
Differential Revision: https://phabricator.services.mozilla.com/D96482
This adds a --enable-bootstrap build flag that will automatically update
cbindgen, node, clang, sccache, nasm, wine, lucetc, dump_syms, pdbstr,
and winchecksec if they are already installed in ~/.mozbuild.
Eventually, we'll want to allow to install toolchains that weren't
already install, but one step at a time.
This explicitly doesn't cover rustc, which is its own can of worms, or
android-{ndk,sdk}, which are not installed via toolchain artifacts
currently.
Differential Revision: https://phabricator.services.mozilla.com/D101723
Now that we use an external dump_syms, we don't need to build
breakpad's.
This means we also don't need the dump_syms_rust_demangle crate anymore.
Differential Revision: https://phabricator.services.mozilla.com/D101865
These are the minimum changes that we need to make to common build system code
to allow us to generate files during pre-export.
We add a `required_before_export` flag to `GeneratedFile` to indicate when a
particular file must be generated in `pre-export`. We set that flag when there
are `.jinja` input files and we're configured for a GeckoView build, otherwise
it is set to `False`.
Then the recursive `make` backend assigns any `GeneratedFile`s that have
`required_before_export` set to run in the `pre-export` tier.
Differential Revision: https://phabricator.services.mozilla.com/D82576
These are the minimum changes that we need to make to common build system code
to allow us to generate files during pre-export.
We add a `required_before_export` flag to `GeneratedFile` to indicate when a
particular file must be generated in `pre-export`. We set that flag when there
are `.jinja` input files and we're configured for a GeckoView build, otherwise
it is set to `False`.
Then the recursive `make` backend assigns any `GeneratedFile`s that have
`required_before_export` set to run in the `pre-export` tier.
Differential Revision: https://phabricator.services.mozilla.com/D82576
There's a macOS-specific wrinkle for browser/ that populates the
`.app` directory. This makes that happen as part of `mach
package-multi-locale`. It's the equivalent, I suppose, of `mach
android assemble-app` for Desktop.
Differential Revision: https://phabricator.services.mozilla.com/D101502
Since zstandard has native code that must be compiled, and that code
uses Python headers, we should be installing those headers as part
of bootstrap.
Most users will have these packages on their machines through various
other means (notably installing `pip`, ie `sudo apt install python3-pip`),
but since it is possible to avoid a pip installation (for example
by installing Mercurial through `yum` and then running bootstrap
immediately after cloning) we should specify these packages as required
by bootstrap.
Differential Revision: https://phabricator.services.mozilla.com/D101479
The current recommendation fails while waiting on user input. Instead, just
save the script to disk as an intermediate step, then invoke it.
Differential Revision: https://phabricator.services.mozilla.com/D101228
Knowing whether `brew` or `macports` is available isn't necessary
to generate the android mozconfig.
This should fix the generation of android mozconfig when a package
manager isn't available.
Differential Revision: https://phabricator.services.mozilla.com/D99496
pylint_requirements.txt fail to install with the new pip resolver due
to a conflict between astroid and lazy-object-proxy.
Rather than bumping those packages and handling the potential fallout,
the package-upgrade has been deferred and we will use the legacy
resolver in the interrim.
Differential Revision: https://phabricator.services.mozilla.com/D99940
The `AUTOCLOBBER` mozconfig option is reliably causing builds to fail when
a clobber is triggered. When we auto-clobber a build we do so after running
`configure` but before running `make client.mk`. This means we destroy all
the gathered information from the `configure` step in the objdir and then
attempt to run `make` using the previously destroyed information.
This commit moves the call to `_check_clobber` to an earlier stage in the
build process, before `configure` is called, so any clobber that takes place
will happen before setting up the objdir via `configure`.
Since `_check_clobber` is only called once in the codebase, and both cases
are now adding clobber metrics one after another, we remove the metrics
gathering from `_check_clobber` and rely on callers to set metrics instead.
Also clean up some nested `if` statements that can be flattened.
Differential Revision: https://phabricator.services.mozilla.com/D100794
This function has a few code paths and has a slightly confusing return value.
Add a comment describing what it does and what the return value actually
means.
Differential Revision: https://phabricator.services.mozilla.com/D100793
Since the printed value is a `str` anyways, this causes the converted `bytes`
to be printed to the terminal as `b'/path/to/topobjdir'`. Just print the `str`
version to the screen instead.
Differential Revision: https://phabricator.services.mozilla.com/D100792
When mach errors out, an error report is sent to Sentry. This error
report contains information about the state of the interpreter during
the failure, details about the environment, installed packages and more.
Having this information available immediately when attempting to resolve
a bug report is generally desirable, instead of going through a back-and-forth
needinfo tag on Bugzilla or spending time asking the reporter questions on
Matrix.
This commit captures the Sentry ID returned from `sentry_sdk.capture_exception`
and prints it to the screen. If a user adds this line to their bug report (as
the error messages suggest) a build team member can enter this number into
Sentry to identify the exact report and debug the error. At minimum this will
reduce the amount of back-and-forth between the reporter and the assignee
required to resolve a bug. Optimally it should make bugs easier to spot and
reduce the time spent on end user support requests.
To use the Sentry ID to identify information about a specific bug report, the
bug assignee should open the Mozilla Sentry page for the `mach` project and
paste the ID into the search box, which will produce the full stack trace with
all submitted information.
Differential Revision: https://phabricator.services.mozilla.com/D100247