The flags added in toolkit/locales/Makefile.in turn out not to be actually
used, so just remove that.
The remaining uses of XULPPFLAGS are to set debug flags depending on whether
MOZ_DEBUG is set or not. Just set a dedicated variable with the right value
from configure.
The order in which backends appear is important, and dealing with deduplication
in configure.in is not really nice, so for all simplification purposes, this relies
on using AC_SUBST_SET, which does the deduplication and keeps the original order
in which items appear (despite its name).
While the name AC_SUBST_SET suggests the underlying type would be a set, it does
not actually matter that much in moz.build, and is not used that much anyways.
Right now, --with-android-sdk expects a path to a specific Android SDK
version, like /path/to/platforms/android-22. That path is exposed as
ANDROID_SDK; the Android SDK root is exposed as ANDROID_SDK_ROOT.
Right now, the provided platform's version number is extracted into
ANDROID_TARGET_SDK. The extracted ANDROID_TARGET_SDK is checked
against a minimum version number (supplied as a parameter to
MOZ_ANDROID_SDK).
After this patch, --with-android-sdk expects what is now
ANDROID_SDK_ROOT, and then derives ANDROID_SDK from that path and a
pinned SDK platform version number. The exact version number which we
search for is now a parameter given to MOZ_ANDROID_SDK. We accept and
fail, with a helpful message, if we recognize an old-style ANDROID_SDK
path.
The existing MOZ_ANDROID_{MIN,MAX}_SDK_VERSION variables remain as
they are.
Right now, the Android build tools are searched in a deterministic but
non-obvious manner. After this patch, the exact build tools version
number is now a parameter given to MOZ_ANDROID_SDK.
This stops exposing ANDROID_BUILD_TOOLS and ANDROID_PLATFORM_TOOLS via
AC_SUBST. We expose most tools already, and this adds EMULATOR, and
consumes it (and ADB) where appropriate.
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!
This commit is us getting out of our own way. We were specifying
-classpath twice, once in $(JAVAC) and once in java-build.mk. Only
the latter of these is active. This a problem for ANDROID_EXTRA_JARS
-- those JARs should be on the classpath and input to $(DX) -- and
JARs that should be on the classpath but *not* input to $(DX). This
commit removes the global flags to $(JAVAC) and adds
JAVA_{BOOT}CLASSPATH_JARS. This required some hijinkery moving
wildcards to moz.build files, but everything seems to work.
As well as clarifying some parts of the build, part 2 uses this work
to modify the classpath.
We build gcc after clang, and extract libgcc libraries and libstdc++
headers from gcc and place them in the clang installation directory in a
way that clang favors before it searches the system for libraries and
includes.
This patch migrates moz_non_memmovable into the CustomTypeAnnotation
framework; bonus side-effects are more helpful error messages and less
code duplication.
