This patch introduces:
1. fetch jobs to fetch python source / installer
2. a) build jobs to build python from source on Linux and OSX
b) build job to manually extract python tree from Windows installer
Some details, per category:
(1) fetches Python 3.8.10 (source) and 3.8.10 (installer).
(2.a) the builds generate optimized version of Python (LTO + PGO)
(2.a) the builds are patched to honor MOZPYTHONHOME instead of
PYTHONHOME. This is used to make OSX builds relocatable, and not
needed on Windows.
(2) zstandard and psutil are added to the default build
Differential Revision: https://phabricator.services.mozilla.com/D164663
This patch introduces:
1. fetch jobs to fetch python source / installer
2. a) build jobs to build python from source on Linux and OSX
b) build job to manually extract python tree from Windows installer
Some details, per category:
(1) fetches Python 3.8.10 (source) and 3.8.10 (installer).
(2.a) the builds generate optimized version of Python (LTO + PGO)
(2.a) the builds are patched to honor MOZPYTHONHOME instead of
PYTHONHOME. This is used to make OSX builds relocatable, and not
needed on Windows.
(2) zstandard and psutil are added to the default build
Differential Revision: https://phabricator.services.mozilla.com/D164663
This patch introduces:
1. fetch jobs to fetch python source / installer
2. a) build jobs to build python from source on Linux and OSX
b) build job to manually extract python tree from Windows installer
Some details, per category:
(1) fetches Python 3.8.10 (source) and 3.8.10 (installer).
(2.a) the builds generate optimized version of Python (LTO + PGO)
(2.a) the builds are patched to honor MOZPYTHONHOME instead of
PYTHONHOME. This is used to make OSX builds relocatable, and not
needed on Windows.
(2) zstandard and psutil are added to the default build
Differential Revision: https://phabricator.services.mozilla.com/D164663
This commit updates the outdated documentation for producing multi-locale
packages, and also arranges for Android multi-locale packages to produce a
GeckoViewExample binary that has `libs` and `assets/omni.ja`. Together, these
greatly ease multi-locale testing.
Differential Revision: https://phabricator.services.mozilla.com/D160705
Following a suggestion from :mkmelin, this seems like an optimal solution: the overriding/duplication in m-c is removed, and all users get a more powerful default choice that they're still able to override with their own, should they so wish.
For clarity and to match other `about:` pages, the shared code is placed under `toolkit/content/`, and all content under `docshell/resources/` is removed.
Differential Revision: https://phabricator.services.mozilla.com/D156478
The way the processor works currently is that it relies on two different
build backends, one of which produces json files for specific
configurations, and the other which produces moz.build files from the
aggregate of all those configs.
Each of these json files is huge, and we actually don't have enough to
support all the platforms we're supposed to be supporting. Adding more
files is not enticing.
Now that we've made the first step described above work in a single pass
on a single machine (as opposed to multiple passes on multiple machines
previously), we can actually merge both steps and avoid producing the
intermediate json files altogether. This will allow to add more
configurations without having to worry about the weight of those files.
And because this all doesn't need to depend on having the first step
hooked up in the build system, we make the whole an independent script
rather than a build backend.
Differential Revision: https://phabricator.services.mozilla.com/D149210
The way the processor works currently is that it relies on two different
build backends, one of which produces json files for specific
configurations, and the other which produces moz.build files from the
aggregate of all those configs.
Each of these json files is huge, and we actually don't have enough to
support all the platforms we're supposed to be supporting. Adding more
files is not enticing.
Now that we've made the first step described above work in a single pass
on a single machine (as opposed to multiple passes on multiple machines
previously), we can actually merge both steps and avoid producing the
intermediate json files altogether. This will allow to add more
configurations without having to worry about the weight of those files.
And because this all doesn't need to depend on having the first step
hooked up in the build system, we make the whole an independent script
rather than a build backend.
Differential Revision: https://phabricator.services.mozilla.com/D149210
The way the processor works currently is that it relies on two different
build backends, one of which produces json files for specific
configurations, and the other which produces moz.build files from the
aggregate of all those configs.
Each of these json files is huge, and we actually don't have enough to
support all the platforms we're supposed to be supporting. Adding more
files is not enticing.
Now that we've made the first step described above work in a single pass
on a single machine (as opposed to multiple passes on multiple machines
previously), we can actually merge both steps and avoid producing the
intermediate json files altogether. This will allow to add more
configurations without having to worry about the weight of those files.
And because this all doesn't need to depend on having the first step
hooked up in the build system, we make the whole an independent script
rather than a build backend.
Differential Revision: https://phabricator.services.mozilla.com/D149210
I wrote this tutorial while documenting my process of adding a
component. I attempted to figure out the process rather than just cargo
culting from examples. The idea is that you can follow along with this
to get a new component going, and then reference the more detailed
documentation for implementation details.
Differential Revision: https://phabricator.services.mozilla.com/D140262
Its layout differs from the one in the tooltool archive for forward
compatibility with the upcoming (clang 15) -winsysroot flag.
There is probably more filtering we can do to somehow match what
windows_toolchain.py used to do, but we'll keep that for later.
Differential Revision: https://phabricator.services.mozilla.com/D143126
Its layout differs from the one in the tooltool archive for forward
compatibility with the upcoming (clang 15) -winsysroot flag.
There is probably more filtering we can do to somehow match what
windows_toolchain.py used to do, but we'll keep that for later.
Differential Revision: https://phabricator.services.mozilla.com/D143126
The existing terminology had two issues:
* `VirtualenvManager` wasn't always associated with an on-disk
`virtualenv`: for example, when running in automation, Mach
"activates" a `VirtualenvManager`, updating its import scope,
but without ever creating an on-disk `virtualenv`.
* An upcoming patch splits the `VirtualenvManager` class, pulling
"on-disk virtualenv-handling functions" from the project-wide
interface for managing Python's import scope.
After some good discussion with Ahal, I think we've struck
the terminology that handles this distinction well: we'll call
the "import scope"-handling part the "site", and we'll continue
to call on-disk virtualenvs (and their representative classes)
as, well, virtualenvs.
Differential Revision: https://phabricator.services.mozilla.com/D130391
Otherwise, the warning is displayed:
```
WARNING: Could not lex literal_block as "json". Highlighting skipped.
```
Depends on D131092
Differential Revision: https://phabricator.services.mozilla.com/D131093
As we leverage the Mach environment more, it becomes increasingly
important that it isn't out-of-date on developer machines.
Add an `up_to_date()` check during Mach initialization.
To minimize the cost to startup, I'm skipping the "pip list" check.
This change required moving `virtualenv` from `mozbuild` to `mach` to
make it available during the early stage of Mach init.
Differential Revision: https://phabricator.services.mozilla.com/D127144
The previous behaviour was to:
* Never add a `pthfile` to the Mach virtualenv, and
* Always add Mach's paths to the `sys.path` when Mach initializes
However, this meant that `pip` would needlessly install packages
that already exist in the vendored environment.
Tweak `pth` behaviour so that `pip` behaves more efficiently.
Differential Revision: https://phabricator.services.mozilla.com/D120402
We've overloaded "bootstrap" to mean three different things:
* The "standalone bootstrap script": `python/mozboot/bin/bootstrap.py`.
This is to freshly clone a new repo, then run `./mach bootstrap`.
* `./mach bootstrap`: Install necessary dependencies and set up the
system for development.
* "Mach bootstrap": do the in-process initialization work Mach needs
before it can run commands.
By using the term "initialize" instead, perhaps we can remove
ambiguity when discussing Mach.
I'm not attached to the name (or this change at all), but I'm interested
in reviewer thoughts :)
Differential Revision: https://phabricator.services.mozilla.com/D120410
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
By hybrid unified system we understand a system that encapsulates modules that are built in the unified mode
but also other modules, like `dom/Animation`, as an example, in the non unified environment.
This approach is desirable since we already have most of the modules transitioned to the non unified system but there are
still some that are not yet compatible, but in the long term this will be done by each module owner and can be also tested
locally using the build system.
If a module can't be built outside the unified method it's `moz.build` config file needs to have `REQUIRES_UNIFIED_BUILD = False`
To also enable this we need to have a flag from `mozconfig`, like:
```
ac_add_options --disable-unified-build
```
Differential Revision: https://phabricator.services.mozilla.com/D122328
By hybrid unified system we understand a system that encapsulates modules that are built in the unified mode
but also other modules, like `dom/Animation`, as an example, in the non unified environment.
This approach is desirable since we already have most of the modules transitioned to the non unified system but there are
still some that are not yet compatible, but in the long term this will be done by each module owner and can be also tested
locally using the build system.
If a module can't be built outside the unified method it's `moz.build` config file needs to have `REQUIRES_UNIFIED_BUILD = False`
To also enable this we need to have a flag from `mozconfig`, like:
```
ac_add_options --disable-unified-build
```
Differential Revision: https://phabricator.services.mozilla.com/D122328
Check if a user is a Mozilla employee by checking their
Bugzilla groups, or checking if their VCS email ends
with "@mozilla.com".
When a user is setting up a new build environment, telemetry
will be automatically enabled for them if they are an
employee. If they're not an employee, they'll be asked
if they want to opt in.
Differential Revision: https://phabricator.services.mozilla.com/D106315
Mark Banner
serge-sans-paille
Cosmin Sabou
Iulian Moraru
Julien Cristau
Mike Hommey
Chris Martin
Sylvestre Ledru
Eemeli Aro
Nick Alexander
ahochheiden
Cristian Tuns
Katherine Patenio
byron jones
smolnar
Andrew McCreight
Greg Tatum
Butkovits Atila
mvollmer
Mitchell Hentges
Gijs Kruitbosch
criss
championshuttler
Andi-Bogdan Postelnicu
Narcis Beleuzu
surajeet310
Alexandre Lissy
Alex Lopez