This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
The few builds that still run on Windows are supposed to be using NSIS
from fetches rather than from from mozilla-build already.
Differential Revision: https://phabricator.services.mozilla.com/D124161
It was moved in bug 1495798 for rusttests, because they didn't use
client.mk, but as of bug 1683797, they do. And it turns out that when
sccache is really started as originally intended, inheriting the make
jobserver, the build is dead-locked until sccache quits (because sccache
still has a jobserver token for some reason). But sccache never quits
when we make it stop outside client.mk.
Differential Revision: https://phabricator.services.mozilla.com/D124728
There is a driver bug on Adreno 3xx devices causing incorrect
rendering when flat scalar varyings are used in fragment shaders. This
has occured several times in different shaders, so this patch finally
adds a test to ensure it does not occur again.
We have used the glsl crate to parse and validate the shaders rather
than angle, as exposing the required bindings to mozangle is messy. We
must therefore use the pre-optimized shaders as the glsl crate does
not handle preprocessor directives correctly.
This has been implemented as a wrench test rather than a unit test as
running unit tests on android is difficult. Additionally we want to
use the shaders specific to the platform the tests are ran on, the bug
only affects (some) android devices, and shaders on other platforms
may differ.
Differential Revision: https://phabricator.services.mozilla.com/D124205
There is a driver bug on Adreno 3xx devices causing incorrect
rendering when flat scalar varyings are used in fragment shaders. This
has occured several times in different shaders, so this patch finally
adds a test to ensure it does not occur again.
We have used the glsl crate to parse and validate the shaders rather
than angle, as exposing the required bindings to mozangle is messy. We
must therefore use the pre-optimized shaders as the glsl crate does
not handle preprocessor directives correctly.
This has been implemented as a wrench test rather than a unit test as
running unit tests on android is difficult. Additionally we want to
use the shaders specific to the platform the tests are ran on, the bug
only affects (some) android devices, and shaders on other platforms
may differ.
Differential Revision: https://phabricator.services.mozilla.com/D124205
There are two big parts in the MSVC toolchain we use:
- the Windows 10 SDK
- Visual C++
For the former, both the 15.8.4 and 15.9.6 toolchains are using the same
version of the Win10 SDK.
For the latter, we're not using the compiler itself anymore, so the only
substantial difference is in the headers and libraries included with
Visual C++, as well as the redist libraries for the CRT. Both versions
are supposed to be compatible to the same set of OS versions, fitting
our system requirements.
This makes us use the same version of MSVC on all our Windows builds
(arm64 builds were already on 15.9.6).
Differential Revision: https://phabricator.services.mozilla.com/D123720
This patch adds a new GeckoView build variant dubbed "lite". We are in the
process of adding some optional dependencies to GeckoView that are needed by
Fenix (like Glean and Nimbus) which are likely not going to be used by anyone
else at Mozilla. To avoid bloating third party consumers, we provide a
geckoview-lite build that doesn't contain any optional dependency.
The min SDK version of GeckoView (non-lite) is being increased to 21 to match
Glean's min SDK. Given that Fenix's min SDK version is already 21 and that the
lite version's min SDK is still at 16 this change is safe to do and will not
incur in any loss of usability.
Differential Revision: https://phabricator.services.mozilla.com/D114370
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
The ARM emulator images have very poor support and haven't been updated for a
long time.
Normally x86_64 images need KVM acceleration which is not available on build
machines (see Bug 1545497). We can work around this by starting the emulator
with the command line |--no-accel|.
Differential Revision: https://phabricator.services.mozilla.com/D119223
This patch adds a new GeckoView build variant dubbed "lite". We are in the
process of adding some optional dependencies to GeckoView that are needed by
Fenix (like Glean and Nimbus) which are likely not going to be used by anyone
else at Mozilla. To avoid bloating third party consumers, we provide a
geckoview-lite build that doesn't contain any optional dependency.
The min SDK version of GeckoView (non-lite) is being increased to 21 to match
Glean's min SDK. Given that Fenix's min SDK version is already 21 and that the
lite version's min SDK is still at 16 this change is safe to do and will not
incur in any loss of usability.
Differential Revision: https://phabricator.services.mozilla.com/D114370
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
The ARM emulator images have very poor support and haven't been updated for a
long time.
Normally x86_64 images need KVM acceleration which is not available on build
machines (see Bug 1545497). We can work around this by starting the emulator
with the command line |--no-accel|.
Differential Revision: https://phabricator.services.mozilla.com/D119223
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
This patch adds a new GeckoView build variant dubbed "lite". We are in the
process of adding some optional dependencies to GeckoView that are needed by
Fenix (like Glean and Nimbus) which are likely not going to be used by anyone
else at Mozilla. To avoid bloating third party consumers, we provide a
geckoview-lite build that doesn't contain any optional dependency.
The min SDK version of GeckoView (non-lite) is being increased to 21 to match
Glean's min SDK. Given that Fenix's min SDK version is already 21 and that the
lite version's min SDK is still at 16 this change is safe to do and will not
incur in any loss of usability.
Differential Revision: https://phabricator.services.mozilla.com/D114370
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
The ARM emulator images have very poor support and haven't been updated for a
long time.
Normally x86_64 images need KVM acceleration which is not available on build
machines (see Bug 1545497). We can work around this by starting the emulator
with the command line |--no-accel|.
Differential Revision: https://phabricator.services.mozilla.com/D119223
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
Nicolas Silva
Alex Lopez
Butkovits Atila
Noemi Erli
Mike Hommey
Connor Sheehan
Jamie Nicol
Marian-Vasile Laza
Alexandru Michis
Aki Sasaki
Ben Hearsum
Joel Maher
Agi Sferro
Agi Sferro
Sebastian Hengst