Since it depends on the `command_handlers` from `Registrar` for the
`file` `sub_command` to determine the appropriate component, we need to
load all command modules so that we can file against any of them.
Differential Revision: https://phabricator.services.mozilla.com/D184853
This just forces other command modules to be loaded in addition to the
'base' command. We need this so that decorators needed by the 'base'
command that are in another command module are ran during initialization
(eg: `@SettingsProvider`).
I thought about centralizing the `@SettingsProvider` decorators into one
module and always loading it, but they can depend on the
'command_handlers' in `Registrar`, so the modules they're currently in
have to be loaded for them to execute, so there wasn't a way around
this.
Differential Revision: https://phabricator.services.mozilla.com/D184852
This is really just shuffling a bunch of things around. None of the
'load_*' member functions of the `Mach` class actually needed to be
member functions. They can all be static so that they can be used
anywhere. That combined with moving all the other 'mach_command' logic
to a different file, allows us to load the module for any command so
that we can successfully dispatch it.
Differential Revision: https://phabricator.services.mozilla.com/D184060
This makes loading almost all commands faster, since only one module
file is loaded rather than all of them. There is one main exception,
dealing with 'help'. Running `./mach help` (or -h or --help) requires
the description text for every command, so every module file is still
loaded.
We could expand this improvement here to consolidate all commands and
their parameters in this `MACH_COMMANDS` dict, but the only two benefits
are improving help, and not having two places where the commands are
specified (their file, and this dict).
There's a lot of extra work needed to do that, especially for handling
sub commands, and it did not seem worth the cost for the benefit at this
time.
Depends on D180499
Differential Revision: https://phabricator.services.mozilla.com/D180500
This activated virtualenv for a command is managed
`CommandSiteManager` and it is passed down to where it was activated
before to prevent a second, redundant, activation.
Differential Revision: https://phabricator.services.mozilla.com/D180499
This makes loading almost all commands faster, since only one module
file is loaded rather than all of them. There is one main exception,
dealing with 'help'. Running `./mach help` (or -h or --help) requires
the description text for every command, so every module file is still
loaded.
We could expand this improvement here to consolidate all commands and
their parameters in this `MACH_COMMANDS` dict, but the only two benefits
are improving help, and not having two places where the commands are
specified (their file, and this dict).
There's a lot of extra work needed to do that, especially for handling
sub commands, and it did not seem worth the cost for the benefit at this
time.
Depends on D180499
Differential Revision: https://phabricator.services.mozilla.com/D180500
This activated virtualenv for a command is managed
`CommandSiteManager` and it is passed down to where it was activated
before to prevent a second, redundant, activation.
Differential Revision: https://phabricator.services.mozilla.com/D180499
We've had this restriction for a while (with a note of it in the docs,
but the note in the docs can easily be overlooked, leading to confusing
errors). Erroring out right on Mach startup and providing instructions
for the workaround immediately should help users get around this issue
faster.
Differential Revision: https://phabricator.services.mozilla.com/D183209
This makes loading almost all commands faster, since only one module
file is loaded rather than all of them. There is one main exception,
dealing with 'help'. Running `./mach help` (or -h or --help) requires
the description text for every command, so every module file is still
loaded.
We could expand this improvement here to consolidate all commands and
their parameters in this `MACH_COMMANDS` dict, but the only two benefits
are improving help, and not having two places where the commands are
specified (their file, and this dict).
There's a lot of extra work needed to do that, especially for handling
sub commands, and it did not seem worth the cost for the benefit at this
time.
Depends on D180499
Differential Revision: https://phabricator.services.mozilla.com/D180500
This activated virtualenv for a command is managed
`CommandSiteManager` and it is passed down to where it was activated
before to prevent a second, redundant, activation.
Differential Revision: https://phabricator.services.mozilla.com/D180499
Also add the associated virtualenv names to each command that has one in
preparation for loading the virtualenvs earlier (next patch).
Differential Revision: https://phabricator.services.mozilla.com/D181032
This reverts bug 1801826 and instead prepends the msys2 path only for
the build, which is a bit more sensible.
This allows us to remove the existing warning from old_configure, since
that can't happen now.
Differential Revision: https://phabricator.services.mozilla.com/D163073
This reverts bug 1801826 and instead prepends the msys2 path only for
the build, which is a bit more sensible.
This allows us to remove the existing warning from old_configure, since
that can't happen now.
Differential Revision: https://phabricator.services.mozilla.com/D163073
This makes sure that we find the right tools in the right msys2
environment in case we get called from another msys2 env.
Differential Revision: https://phabricator.services.mozilla.com/D162753
Added `mach uniffi generate` which executes `uniffi-bindgen-gecko-js` to
generate UniFFI bindings. It's unfortunate that we need to check these
files in, but I couldn't figure out a way to auto-generate them as part
of the build process.
Adding `#include "nsIContent.h"` to dom/base/nsINodeList.h. I think
that should have been present before, but things built okay because of
the way things got combined in the uniffied .cpp files. Adding these new
webIDL files bumped `NodeListBinding.cpp` to a new uniffied .cpp file
which caused the build to fail.
Differential Revision: https://phabricator.services.mozilla.com/D144468
Added `mach uniffi generate` which executes `uniffi-bindgen-gecko-js` to
generate UniFFI bindings. It's unfortunate that we need to check these
files in, but I couldn't figure out a way to auto-generate them as part
of the build process.
Adding `#include "nsIContent.h"` to dom/base/nsINodeList.h. I think
that should have been present before, but things built okay because of
the way things got combined in the uniffied .cpp files. Adding these new
webIDL files bumped `NodeListBinding.cpp` to a new uniffied .cpp file
which caused the build to fail.
Differential Revision: https://phabricator.services.mozilla.com/D144468
As per the docs:
> Return the number of logical CPUs in the system (same as os.cpu_count in Python 3.4) or None if undetermined.
> [...] On OpenBSD and NetBSD psutil.cpu_count(logical=False) always return None
Glean tries to coerce values to the expected type. `None` cannot be
coerced to an integer, so this blows up.
We conditionally report that value now only if we can properly detect
one.
Differential Revision: https://phabricator.services.mozilla.com/D149201
When using Mach outside of MozillaBuild, rather than avoiding adding
paths entirely if any part of MozillaBuild is already in the `PATH`,
instead conditionally add each one if it doesn't exist already.
This ensures no duplication of paths, while also correctly handling the
not-uncommon case of developers manually adding MozillaBuild's Python to
their Windows `PATH`.
Differential Revision: https://phabricator.services.mozilla.com/D141377
Windows uses `;` as the path separator, Unix-based systems use `:`.
`os.pathsep` conveniently represents the current system's separator.
All OS-specific path separators have been replaced with `os.pathsep`
except for some explicitly Windows-specific mozharness configs.
Differential Revision: https://phabricator.services.mozilla.com/D140981
ahochheiden
Natalia Csoregi
Sandor Molnar
nicklas boman
Cosmin Sabou
Iulian Moraru
Marco Castelluccio
Emilio Cobos Álvarez
Marian-Vasile Laza
Mike Hommey
Mark Striemer
Ben Dean-Kawamura
Butkovits Atila
Jan-Erik Rediger
Barret Rennie
Tooru Fujisawa
Bas Schouten
Mitchell Hentges
Thomas Wisniewski