This patch adds the ability to run foreground resource tests on `fenix`
and `chrome-m` by slightly modifying the existing background resource
test. For now the main difference is just sending the app process to the
background or leave it in the foreground. Some folders/files are renamed
appropriately from `background-resource` to instead `android-resource`.
Differential Revision: https://phabricator.services.mozilla.com/D221386
We were previously running dbus twice: once as part of the X session scripts,
with all the gnome things, and a separate one for our tests and a gnome-keyring
daemon that test-linux.sh runs. By launching dbus before the X session
scripts, they can all share the same bus and firefox in tests can talk to the
other services listening on that bus.
Differential Revision: https://phabricator.services.mozilla.com/D221068
I messed up my earlier try push so that didn't actually fix anything. I believe
the workers are also setting PIP_NO_INDEX=1, so we also need to disable this.
Differential Revision: https://phabricator.services.mozilla.com/D221408
We were previously running dbus twice: once as part of the X session scripts,
with all the gnome things, and a separate one for our tests and a gnome-keyring
daemon that test-linux.sh runs. By launching dbus before the X session
scripts, they can all share the same bus and firefox in tests can talk to the
other services listening on that bus.
Differential Revision: https://phabricator.services.mozilla.com/D221068
By doing so, we don't really need a stage 1 clang for mac and windows
(with the downside that the final PGOed clang becomes the
clang-toolchain artifact on those platforms), and cross-compiling stage
2 is much faster as a cross-compile, leaving only stage 3 to be native.
While here, for the one build type that still does stage 2 and 3 in one
task, we actually prefer taking the llvm-profdata from stage 1, as it
doesn't contain profile instrumentation (it should actually have been
this way since the beginning).
Differential Revision: https://phabricator.services.mozilla.com/D220654
By separating the "use this compiler" configuration from other items,
we avoid redundancies, and at the same time simplify how the aarch64
variants are configured by having the $os_variant.json files only
contain the `target`.
Overall, each build now only uses at most 4 configs:
- one for the compiler it uses
- one for the target (optional when the host is the same as the target)
- one for the patches applied to the clang/llvm source
- one for the build type (stage-1, profile or stage-4-pgo)
And a similar pattern for clang-tidy.
Also remove the setting for ld, which hasn't been used since bug
1799423, and ranlib and ar for builds using clang-cl, as it's not used
either.
Differential Revision: https://phabricator.services.mozilla.com/D220652
We have groups for 32-bits linux and aarch64 linux that aren't used
consistently, and we could use some similar grouping for aarch64 mac and
windows instead of adding aarch64 to their symbol names.
Differential Revision: https://phabricator.services.mozilla.com/D220537
This splits the clang build in the necessary steps to get native
profiles for Intel and Arm64 mac, similarly to Linux.
Stage 1s are cross-compiled, and the profile step runs natively.
Differential Revision: https://phabricator.services.mozilla.com/D220530
While we are building cmake from source on Windows, that's only because
we're patching it to work around a cmake issue on Windows. We used to
use a binary on Windows before, so we don't shy away from using a binary
on mac.
Differential Revision: https://phabricator.services.mozilla.com/D220528
