This commit exposes test-deps file info as a mach command, and
modifies the test scheme reader to make it filter out unsuitable
contexts when generating TestManifest objects for metadata context.
--HG--
extra : commitid : 7QOoHkfvWOF
This bumps the NDK version to r10e.
Previously, we used brew to install android-sdk and a custom version
of android-ndk. That makes it hard to control the installed versions.
This installs from downloaded archives, which unifies the Mac OS X
approach with the straight-forward Linux approach.
--HG--
extra : commitid : E7hEqsyy8Gw
extra : rebase_source : 9ea27e7d2ae3fbaaa3efbabdd701521981bec877
extra : histedit_source : c07c80c50ac066dc6808e7ccf96f0bc14dc09df2
The 'tools' package depends on 'platform-tools-preview' now. Roll
with it until Google breaks us back again.
The behaviour of the |android| tool has changed; recent versions don't
reveal what packages are installed. That means we can't skip already
installed packages; and we can't really tell if our installation
attempts succeeded. But we have faith!
--HG--
extra : commitid : 341NxbHTJXC
extra : rebase_source : 945e8018effc0b417fc3fedb7220455fabeaedb3
extra : histedit_source : e42fb06e176d5b9e9ebb6553af7045f3a061105f
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
This included adding the slugid 1.0.6 python source code in /python since slugid
is now a dependency of the ./mach taskcluster-graph command, as well us updating
references that used it. Previously the implementation was in-tree.
Previously, we used a PPA on Ubuntu to install Mercurial. The PPA has
proved to be unreliable. Furthermore, we didn't have a mechanism for
installing a modern Mercurial on Debian and other derived distros.
In this commit, we remove the PPA from Ubuntu. We add the ability to
install Mercurial from pip to the Debian bootstrapper. However, since
some people may not want <not apt> installing package-like things,
we add a prompt explaining the situation and giving users a choice.
We recommend installing a modern Mercurial via pip. But we also given
the option to install a likely legacy version via apt. And, for Git
users, we give the option to not install Mercurial at all.
Since the new version of the Ubuntu bootstrapper is empty, it doesn't
need to exist, so it has been removed.
DONTBUILD (NPOTB)
--HG--
extra : commitid : 1n8D8hTG6Fm
extra : rebase_source : 666d9945650c0ce27a32353d98886e2336628a36
extra : amend_source : bb9e7538157fdac0203e2ecc3165185f95717098
Android version codes serve multiple masters. They indicate newer
versions, yes; but they also break ties between versions with
different features and requirements. High order bits effectively
partition the space of versions and are valuable. Since Android
version codes are signed Java integers, we have 31 bits to work with.
Mozilla's traditional build ID is YYYYMMDDhhmmss. This was chopped to
ten characters (YYYYMMDDhh, i.e., hourly build IDs) and then converted
to a decimal. This took many high order bits. We will lose another
high order bit in the 36th month of 2015 -- i.e., as soon as the year
rolls over to 2016. If we waited to lose the next higher order bit,
we'd lose that one in the 46th month of 2017 -- i.e., as soon as the
year rolls over to 2018.
The following patch sacrifices a high order bit to change the version
scheme, winning us roughly 15 years of hourly build IDs before we are
forced to lose another high order bit. So it's clearly to our
advantage to change the scheme sooner rather than later -- we will
sacrifice 1 bit for 15 years of build IDs, rather than keeping the
current scheme and sacrificing (say) 2 bits for 3 years of build IDs.
The resulting scheme produces build IDs that look like (in binary):
0111 1000 0010 tttt tttt tttt tttt txpg
The meaning of these build IDs is documented in the Python source code
that generates them.
--HG--
extra : commitid : 7BEkkGHsYVL
extra : rebase_source : bbc0ead8e7a383c320e838b023b02b1fb0d94ff3
extra : amend_source : dab8c737e3274694aad40123e77884a3239908de
extra : histedit_source : 530bedde3695d534805465cdf8bcb9cd23f7b031
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
This moves a little bit more of mobile/android/base/Makefile.in into
moz.build, and gets closer to moving that aapt invocation into
java-build.mk.
There are no other extra package consumers in the tree. (There should
be a new one shortly: b2gdroid.)
--HG--
extra : commitid : AaYqXYReOSX
extra : rebase_source : d41368ff0bd0736221fdc04ed8299b70c2488c8b
extra : histedit_source : 845efd5ba9f99f4e186c3a5c66affe69eac7fec7
This paves the way for defining additional Android packages in
moz.build, which is a step toward moving the special
mobile/android/base/Makefile.in aapt invocations into the generic
java-build.mk framework.
The new variables are both passthru variables for now: in the future,
we'll roll them into some aggregate Android APK definition.
It's worth noting that references to the variables in Makefile.in
files are only defined after including rules.mk (and thereby
backend.mk). This only required a few changes in the tree but it
confused me for some time.
--HG--
extra : commitid : G5mEvm8Ng4F
extra : rebase_source : 7ba05f2e53554549ffb5cefe270925e3e2025b6a
extra : histedit_source : eacd22f4b7edddab67147c413fea45a3ba292c0c
Over a 19 minute build, |mach build| was spending ~45s drawing the TIER footer. This brings it down to ~30s.
--HG--
extra : commitid : 2sLWbNL853A
extra : rebase_source : ab8452dfa6ac39bc40a8f22b542e155595f18881
This change adds a 'what' parameter to |mach clobber| which facilitates clobbering other things as well.
E.g, |mach clobber python| now clobbers all .pyc and .pyo files in the tree. Multiple clobber targets can
be specified, e.g |mach clobber objdir python|. By default |mach clobber| without arguments will only
remove the currently active objdir, the same as before.
--HG--
extra : commitid : 4mJqdnWPRbH
extra : rebase_source : cf56de2d51c57747047936f7e742bafbf3f91c9f
We have had singular ANDROID_ASSETS_DIR in Makefile.in for a while.
Fennec itself does not use the existing Makefile.in Android code, for
complicated historical reasons.
This makes the existing variable moz.build-only; generalizes the
existing variable to an ordered list; and adds the equivalent use of
the new list to the Fennec build, with a simple example asset.
This patch also updates the packager to include assets packed into the
gecko.ap_. Without the packager change, the assets/ directory in the
ap_ gets left out of the final apk. This whole approach is totally
non-standard but is more or less required to support our single-locale
repack scheme.
--HG--
extra : commitid : 4EAh1UNGNWT
extra : rebase_source : 5e5b4c4a120c3b4cc776c9f9380ddd2f9b63587e
extra : source : 0ddce3eb833e6d6180a19928a9b45d5d12f1d7fa
This patch does a few things. First, it adds an AbsolutePath data
type, sibling to SourcePath and ObjDirPath. (Existing Path consumers
that accept an open set of Path subtypes, and that only use full_path,
should function fine with the new AbsolutePath subtype.)
Second, it moves ANDROID_RES_DIRS to a moz.build list of Paths
(ordered). We test, but don't use in tree, the new AbsolutePath.
--HG--
extra : commitid : DMLy1ogTJ0Y
extra : rebase_source : cb9ac47e8bf7c893a0284adc7a42eccb78ccae3d
Mach has special handling for remainder arguments which previously
only worked with the decoration form. Extend this to also work when
a command passes in an explict parser
--HG--
extra : commitid : ICnYk764Xbc
extra : rebase_source : 1518edcb7bef375cbc2931b8da54b015045c8ce1
It is useful to be able, during mozconfig execution, to do tests depending
on what was previously added with mk_add_options. Specifically, there is a
need to do this for MOZ_PGO because developers pushing to try may add it to
mozconfig.common.override.
While, ideally, it would be nice if we just defined the variable itself in
the mozconfig execution environment, that is a tedious task, having to jump
through hoops with eval, and handle all cases of variable assigment properly.
The hacky alternative is to just treat MOZ_PGO specially, but meh.
So instead, we set a ${var}_IS_SET variable to 1, indicating that a
mk_add_options defined ${var} to some value.
Bug 1153566 changed the regexp used in that method in such a way that there
has been a big hit in the time spent executing the make backend. On my machine,
with the current code, mach build-backend indicates:
Backend executed in 5.01s
With the change from bug 1153566 reverted:
Backend executed in 2.97s
That's a significant regression for a 4-character change.
But we can actually avoid using regexp in most cases, which can make things faster
than they were. With this change, we get down to:
Backend executed in 2.28s
For reference, making the _check_blacklisted_variables method do nothing at all
ends with:
Backend executed in 2.20s
DONTBUILD NPOTB on a CLOSED TREE
--HG--
extra : commitid : 2ft26PqDgyT
extra : rebase_source : ca2eb4fe7c04e97fb78cd2175bd8549e13c13d7e
extra : amend_source : 10a2fa5931d151af448269239bdf2dc1980d3fae
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.
--HG--
extra : commitid : CnJKouGgkh1
extra : rebase_source : 5767e66ea53e14dd6468adec741773a02a6e2d3a
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.
--HG--
extra : commitid : 89l5oW9T8ks
extra : rebase_source : f402353cd4a759c882475518f1360687af1936dc
extra : amend_source : ec31a39620eae2c90fb832f314cd161905444a34
This will give us the ability to execute custom code at command dispatch
time. We can use this for global tests before dispatch.
--HG--
extra : commitid : 5vfmSqOis4W
extra : rebase_source : c285b16007c4b604b164d079a275198c8760e480
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.
--HG--
extra : commitid : 8dfw1ri7qjr
extra : rebase_source : da0e5ec705e0ac4c795bd2d7892f73857a1699ac
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.
--HG--
extra : commitid : JvvZDrjUOQZ
extra : rebase_source : f48c1a9d4b506b6ed931043aeeaca437418ea9c3
extra : histedit_source : 3dbfd049039c0adc595c1abb0df3dca3af9db207
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.
--HG--
extra : commitid : 4GC5lJWrBFq
extra : rebase_source : c91674b16f29dadf8dcda460787ea94654f2864a
This is a regression from bug 1176620 that results in all Firefox mach commands showing up in the help for B2G, even though they don't work there.
--HG--
extra : rebase_source : e779b866a82c2df1dbf913d24b93a0dc9838ff9f
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.
--HG--
extra : commitid : 4CJqlwDqOVg
extra : rebase_source : 9dbbd69291d64b894a399523864562107c10872e
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.
--HG--
extra : commitid : GdXsF7agvCT
extra : rebase_source : 586f1960c8e7eb400f61467045b064167784f68b
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.
--HG--
extra : commitid : 6tFME1KKfTD
extra : rebase_source : 78728f82f5487281620e00c2a8004cd5e1968087
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.)
--HG--
extra : commitid : 1T28aVfArqF
extra : rebase_source : b8c11244de8be0a14d605853f30cd47312d0a4ba
extra : histedit_source : 78a224501cd3cf0f86707c9c9549b61b4b248ba7
This type is now redundant with our new rich type for capturing all mach
command metadata. Eliminate it and using _MachCommand instead.
--HG--
extra : commitid : 7pXhf6V7F8m
extra : rebase_source : 343615096f23d3acf23f7487c7b8c7137c85337e
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__.
--HG--
extra : commitid : I5PRlYDVXVq
extra : rebase_source : ebf07116357036ddfec06fd32fb161fefff628e6
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.
--HG--
extra : commitid : EtBwUmS5TV2
extra : rebase_source : 4ef5f95a532693672c6c4b33fa1c22adb76d105e
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.
--HG--
extra : commitid : F55RzhDCVmR
extra : rebase_source : 1fe1a03f8d592c60d2ed8d760fd62c7bc60421a5