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.
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.
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.)
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.
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.
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.
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.
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
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
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.
