This changes the minimum macOS target from 10.12 to 10.15 in several build
scripts and in documentation that references the minimum version
requirement.
Differential Revision: https://phabricator.services.mozilla.com/D184432
This makes a few changes to clarify messaging:
* Documentation now mentions cargo vet and says that all vendored crates must be audited.
* A message is printed when vendoring fails, making it clear that no new crates were vendored.
Differential Revision: https://phabricator.services.mozilla.com/D180712
This makes them switch to private_local_toolchain.sh, which wraps a call
to `mach python --virtualenv build taskcluster/scripts/misc/$script`
Differential Revision: https://phabricator.services.mozilla.com/D175445
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
