This just allows a little versatility for consumers such as b2gdroid,
which are Fennec-like but don't have MOZ_APP_NAME=fennec.
I elected to pass appname as a parameter rather than modify the
existing distdir because I expect to want to differentiate, in some
way, the output AAR files based on the underlying name. That is, in
future we might generate geckoview-fennec-VERSION.aar and
geckolibs-b2gdroid-VERSION.aar, or stuff the name into the Ivy version
information, or...
This also fixes a typo in one of the JarFinder instantiations.
CalledProcessError.output and subprocess.check_output's return value
are str types. This file uses unicode_literals. If we do something
like `if 'foo' in e.output`, there will be a mix of str and unicode
types and Python will do implicit conversion. If the strings aren't
ASCII, we'll likely encounter a UnicodeDecodeError.
Use b'' literals around all strings to prevent this coercion from
occurring.
Move Python code into an xpidl subdirectory, and include a setup.py to allow
inclusion from pip install or requirements files. Change build directory
variables appropriately.
I considered three ways to do this:
* one, as a Python script executed with $(shell);
* two, as a Python script that writes an include file for the preprocessor;
* three, as a function exposed to the moz.build sandbox.
I rejected two because it's both tied to the preprocessor, and awkward
to make handle the dependency on the buildid (in a file) and
additional build defines (in config.status).
I rejected three because I know of no precedent for this approach, and
it hides the dependency on the buildid.
One doesn't handle failures in the script gracefully, but neither did
the existing approach. This patch is at least testable.
Without this, we throw UnrecognizedArgumentError when running commands
such as `./mach mochitest-plain test`, which causes an error message
such as the below to be emitted:
It looks like you passed an unrecognized argument into mach.
The mochitest-plain command does not accept the arguments: test
This patch will fix the above command to instead print the corresponding
deprecation message.
DONTBUILD NPOTB
This was just an oversight during the initial landing, leading to two
copies of artifact libraries being appended to the same destination
file.
This implements a new "scan" mode for DMD that records the address
and contents of every live unsampled block in the DMD log. This
enables the low-level analysis of references from one block to
another, which can help leak investigations.
bf34d16b6ab2 added absolute_import to this file. When changed, "import
mozinfo" stopped picking up mozbuild.mozinfo and started importing
mozinfo instead.
Use relative imports to force mozbuild.mozinfo to be picked up.
This was the only import of glob from all mach_commands.py files. Kill
it.
With this commit, there are no modules imported by a single
mach_commands.py outside of testing/web-platform/mach_commands.py.
This import brought in significant parts of the mozbuild package. Moving
it to a deferred import reduces the total number of Python modules
imported during mach dispatch by 43.
This removes ambiguity as to which modules are being imported, making
import slightly faster as Python doesn't need to test so many
directories for file presence.
All files should already be using absolute imports because mach command
modules aren't imported to the package they belong to: they instead
belong to the "mach" package. So relative imports shouldn't have been
used.
DONTBUILD ON A CLOSED TREE: Android-only and the build changes are cosmetic.
Very much a first cut, but I'd like to get some Fennec early adopters testing.
This adds:
* |mach artifact install| to fetch and install Fennec binaries;
* |mach artifact last| to print details about what was last installed;
* |mach artifact {print,clear}-caches|, for debugging.
This code is exposed as a new mozbuild.artifacts Python but it's not
particularly general. My intention was to get things out of the mach command
more than produce a general artifact fetching API. We can leave that bike
shed to Bug 1124378.
I've been testing this with --disable-compile-environment and it works well
locally, although there's no reason a knowledgeable developer couldn't use
this in conjunction with a fully-built tree. (I don't know when such a
situation would arise, but I know of no technical impediment.)
Simplify construction of mach's MethodHandler instances by by passing in
our new rich type that holds all command metadata.
While we are here, kill the docstring argument, as it can be computed
easily inside MethodHandler.__init__.
Up to this point, mach command metadata has been stored in tuples.
Initially, things weren't so bad. But they have evolved into tuples with
many elements. Adding new attributes is cumbersome. Let's restructure
the code to capture metadata in a dedicated class.
Before, there existed a separate attribute on the @Command or
@SubCommand decorated method for each mach decorator: @Command,
@CommandArgument, @CommandArgumentGroup. With the magic of __ior__,
we can now capture all metadata on a single type. This simplies
processing, as we now only look at a single attribute on methods:
_mach_command.
Before, we used separate attributes to distinguish between mach commands
and mach sub-commands. Now that we have a type that can hold all data,
we combine things into the _mach_command attribute and look for the
presence of the "subcommand" attribute on this type to identify
sub-commands.
We want this logic to live next to where metadata types are defined so
downstream consumers of Files-based metadata don't have to reinvent the
wheel.
The work in this commit will be used to enable auto filing bugs during
pushes to MozReview.
