The manifest file hasn't actually done anything since XPT definitions were
moved to the libxul binary, and now just generates warnings in local builes.
Differential Revision: https://phabricator.services.mozilla.com/D89197
The manifest file hasn't actually done anything since XPT definitions were
moved to the libxul binary, and now just generates warnings in local builes.
Differential Revision: https://phabricator.services.mozilla.com/D89197
I think they're remnants from the past that we don't really need anymore.
And they're making things more complicated for some pending work of mine.
Differential Revision: https://phabricator.services.mozilla.com/D89687
Allows mach commands to define their own glean metrics with the `metrics_path` @CommandProvider parameter.
When `metrics_path` is defined:
* A `metrics` kwarg is provided to the decorated class. This `metrics` handle is a Glean instance, so Glean documentation should be consulted for usage information.
* When `mach doc telemetry` is run, metrics docs will be generated from all the registered metrics files.
Note: there was some consideration between making `metrics_path` a @CommandProvider or @Command parameter.
In the end, @CommandProvider seemed like a better fit because:
* Metrics seem to be more associated with the entire class than a specific command/method. This is because a class represents a "domain", and that domain may have different commands that have overlapping metrics. Accordingly, all the metrics should be defined once as available to the entire class.
* Currently, @Command methods only take parameters that map one-to-one with CLI arguments. It could seem inconsistent to have one exception: the metrics handle
Differential Revision: https://phabricator.services.mozilla.com/D85953
In the patch for bug 1656993, the case in which
get_command was being set was removed.
Accordingly, its usage in CommandAction will always be evaluated to
`False`, and it can be deleted.
Differential Revision: https://phabricator.services.mozilla.com/D90198
When multiple java versions are in use, some OSes have a mechanism to
change the "default"/system Java.
This can cause unexpected build failures if the system Java changes.
So, in bootstrap, if the Java version found is valid, then its path
should be encoded into mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D90163
This was originally meant to allow `virtualenv`s to use packages from a parent Python environment without having to re-install them. This turned out to not pan out as we would have liked, so we're going another way to solve the same problem. Bug 1660351 walked back a bunch of this logic; this patch deletes the rest of it.
Differential Revision: https://phabricator.services.mozilla.com/D89492
I think they're remnants from the past that we don't really need anymore.
And they're making things more complicated for some pending work of mine.
Differential Revision: https://phabricator.services.mozilla.com/D89687
The idea here was that we keep the NDK's downloaded in this directory as a "cache", such that if the download gets interrupted, then we can resume the download from an earlier point. This logic was walked back by bug 1637379, which deletes the cache.
In the spirit of the original version of the code, remove the `os.rmdir()` that was introduced by that bug.
An alternative fix for this is to download the NDK to a temporary directory and just clean that up entirely after every call to `mach bootstrap`, but then we would be forgoing the build cache behavior, which I'm not sure makes sense at this point in time.
Differential Revision: https://phabricator.services.mozilla.com/D90125
VSCode doesn't install by default it's command line integration toolset on MacOS
so w don't have a link to `/usr/local/bin/code` instead we must use the binary from the
`Applications` folder.
Also extens this to other platforms even though it's improbable that we are going to use it
there.
Differential Revision: https://phabricator.services.mozilla.com/D90088
In bootstrap, pacman should ensure its database is up-to-date.
Otherwise, when installing packages, pacman will slowly query every
mirror when attempting to download an out-of-date package.
Differential Revision: https://phabricator.services.mozilla.com/D89958
In addition to the existing build telemetry, also gather the stats and
report with Glean. This new telemetry is reported in tandem with the existing
telemetry to allow testing and confidence before a full roll-out.
Additionally, Glean isn't compatible with Python 2, so the new telemetry only runs
on Python 3 mach commands.
Differential Revision: https://phabricator.services.mozilla.com/D83572
This was originally meant to allow `virtualenv`s to use packages from a parent Python environment without having to re-install them. This turned out to not pan out as we would have liked, so we're going another way to solve the same problem. Bug 1660351 walked back a bunch of this logic; this patch deletes the rest of it.
Differential Revision: https://phabricator.services.mozilla.com/D89492
This commit does the following.
- Renames `slashslash` as `dumbComments`. As a result, it now comes before
`emptyLines` in alphabetical ordering, which means that if you apply both
`dumbComments` and `emptyLines`, lines that contain only comments will be
fully removed.
(I contemplated changing the filter ordering to match the order specified,
rather than using alphabetical ordering, but that was more invasive and not
obviously better.)
- Changes `dumbComments` so it only applies if the comment is at the start of
the line (with optional leading whitespace). This is so it can be used with
prefs files, which contain lines like `pref("foo", "https://mozilla.org");`
where the `//` must not be treated as a comment.
Note that `slashslash` wasn't being used anywhere.
Depends on D88240
Differential Revision: https://phabricator.services.mozilla.com/D88242
It's not used, probably because it's pretty strange and hard to imagine using
safely. (Stripping leading and trailing space could be useful, but collapsing
sequences of spaces? Hmm.)
Differential Revision: https://phabricator.services.mozilla.com/D88240
The llvm-strip from clang-11 complains about this file. This file doesn't really interest us anyway -- it's imported from elsewhere -- so just avoid it.
Differential Revision: https://phabricator.services.mozilla.com/D89491
`bootstrap` is written in such a way that we don't necessarily assume the existence of either the global state directory (`~/.mozbuild`) or a local checkout of `mozilla-central`. The independence from `~/.mozbuild` is a design decision that may have been appropriate at some point, but today it's arguably useless to continue executing `bootstrap` without a global state directory (we install a bunch of build dependencies there, as well as the `mach` `virtualenv`s that are needed for running non-`bootstrap` `mach` commands after bug 1656993). The independence from a local checkout is an artifact of the old design of `python/mozboot/bin/bootstrap.py`, which is no longer necessary as of bug 1647792.
With that in mind, 1) throw errors if we can't create the global state directory or find the topsrcdir, and 2) remove all existing conditionals of the form "if the global state directory exists" or "if the root of the checkout exists" since these conditions are always going to be true in practice.
Differential Revision: https://phabricator.services.mozilla.com/D89220
This will be found in a couple places, so we might as well make a helper function. For symmetry put it in the same file where we keep the helper function to locate the `state_dir`.
Differential Revision: https://phabricator.services.mozilla.com/D89156
Gregory Mierzwinski
Kris Maglione
Dorel Luca
Ricky Stewart
Mike Hommey
Mitchell Hentges
Tarek Ziadé
Razvan Maries
Tom Ritter
Alexis Beingessner
Andi-Bogdan Postelnicu
Mark Banner
Gijs Kruitbosch
Narcis Beleuzu
Mihai Alexandru Michis
Csoregi Natalia
Myeongjun Go
Nicholas Nethercote
David Major
Andrew Halberstadt
Sylvestre Ledru