Now that all the conflicts in python dependencies that made the
new pip resolver fail have been resolved, we no longer need to support
the legacy resolver that was added as a temporary measure.
Depends on D106154
Differential Revision: https://phabricator.services.mozilla.com/D106503
We're not 100% certain if Help is the right spot for this, but we're going
to give it a shot and see. If it turns out it _is_ the right spot, we'll
probably do something a little more self-contained, and less hacky.
I'm leaving the old .properties file just in case we change our mind here.
Yes, we'll want to port to Fluent anyways, but our ultimate choice of where
we put this thing is probably going to dictate where the string lives.
Differential Revision: https://phabricator.services.mozilla.com/D104832
Bug 1476231 actually removed libav, so we don't build it, and don't need
neither the yasm check nor the LIBAV_FFT_ASFLAGS variable.
However, we still have checks, both in moz.build and code, for
MOZ_LIBAV_FFT, so we need to keep that.
Differential Revision: https://phabricator.services.mozilla.com/D105399
* We add new options to the Android variant of `mach run`:
* `--debug`: enables running with a debugger;
* `--debugger`: Allows the user to override the default debugger (`lldb`).
The provided argument must still be `lldb` compatible; this
is for enabling the ability to specify some kind of wrapper
script or other debugger front-end, if desired;
* `--debugger-args`: Additional arguments to pass to the debugger's command line;
* `--no-attach`: Runs the app and prepares the device for debugging, but does
not actually attach any debuggers. The required ports are
printed to the log, and then `mach` exits, thus allowing for
the user to manually connect.
* `--use-existing-process`: This allows the user to attach to an existing
process, instead of killing existing process(es)
and starting from scratch. This is useful for
users who want to attach to an existing process
that is already in a desired state.
When debugging is enabled:
BEFORE the app starts:
* `verify_android_device` will install `lldb-server` if necessary;
* We run `am set-debug-app -w --persistent` to ensure that the app is set as the
device's debug app. Since we pass `-w`, when Android starts the target app, it
will wait for `jdb` to attach before proceeding.
AFTER the app starts:
* We start `lldb-server` and obtain the name of its socket file;
* We obtain the pid of the parent process. Alternatively, if
`--use-existing-process` was specified and there are already extant child
processes, we prompt the user to choose which process to which they would
initially like to attach.
* We forward a local TCP port for `jdb` debugging.
* We run `jdb` in the background to connect to the process and then quit.
This is solely for the purpose of dismissing Android's "waiting for debugger"
dialog.
* In the foreground, we run `lldb`, specifying a set of initial commands that
are required to for symbol resolution and to automatically connect to the
target pid.
Why `lldb`? I chose it for consistency with Android Studio. Somebody else is
welcome to implement `gdb` support if they wish. :-)
Differential Revision: https://phabricator.services.mozilla.com/D94384
NDK 21 includes `lldb-server`, which we need in order to support
`./mach run --debug` with `lldb`.
The Android SDK manager no longer includes a standalone `lldb` package; perhaps
it was deprecated? Anyway, this appears to currently be the best way to get
`lldb-server` into a location that is easy to find during build configuration.
Differential Revision: https://phabricator.services.mozilla.com/D94379
The subprocess.* wrapping in configure alters the environment sent
to the subprocess in two ways:
- variable keys and values are normalized to unicode to make python
happy.
- when no explicit environment is passed, default to the sandbox
environment.
The sandbox environment has one major difference with the original
environment, which is that PYTHONEXECUTABLE is unset, and that's known
to cause problems on mac, which it does when configure executes
`mach artifact toolchain` for --enable-bootstrap.
Differential Revision: https://phabricator.services.mozilla.com/D105265
Indidentally, this fixes the failure code path, because the change in
bug 1692103 was such that the logger output was not captured in `out`.
Differential Revision: https://phabricator.services.mozilla.com/D105390
As far as I can tell, we don't use zstandard from python2. As the last
version supporting python2 is 0.14.1, drop installing the python2
version.
Differential Revision: https://phabricator.services.mozilla.com/D105075
* Puts the docs in order, so that contributors aren't jumping to the
middle of the page to install system tools, then back to the top to
clone Firefox.
* Removes docs on MacPorts since it's being removed in bug 1688263.
* Removes step to manually install brew packages since that happens
automatically in bootstrap now.
* Simplifies mercurial installation docs
* Removes unnecessary mozconfig-tweaking instructions
* Removes almost-always-unnecessary DEFINE and troubleshooting
information.
Differential Revision: https://phabricator.services.mozilla.com/D102973
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