This patch also adds the new base (sic) library play-services-basement.
Note that the package names have changed too:
* play-services-base: com.google.gms -> com.google.gms.base
* play-services-basement: * -> com.google.gms
--HG--
extra : commitid : EcmxZA10rzV
extra : rebase_source : f39b361807a0b8227f3fb9a6d73e066241c8e36c
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.
--HG--
extra : commitid : 7z4T3EYH8fg
extra : rebase_source : 118a2a163d0deb1896e4959f12e9fbb132732bd8
extra : histedit_source : f18feda343e3c8e9f0dbb65eb7127262690e3cad
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.
--HG--
extra : commitid : 9u0pibgE00
extra : rebase_source : 04e420c53d1d75ab8f055436d7dd69e148168c67
extra : histedit_source : a930a34f4dda44ee91b52caf68e02877b0502f01
This merely groups the AAR searches in the configure output, which
reads a little easier.
--HG--
extra : commitid : 8yoM0J2NNOq
extra : rebase_source : 989bf064ca0f2d4e0126726dad7529a218e11e62
extra : histedit_source : f8c211e64741b4558b185bfbf5523b67cc428232
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
The PR was fixed in early 2011. clang 3.3, the oldest version of clang
that we build with, was released in mid-2013. It's safe to say that all
versions of clang now have this fix, and we can delete the check.
Trying to decipher MOZ_SUBCONFIGURE_ICU given its lack of indentation is
difficult at best. It looks like some lines have tabs, and those tabs
make everything line up right...convert everything to spaces to make
sure things line up correctly.
We require ndk-r8e, so we don't need to support paths for all the other
NDKs prior to that now. Also took the opportunity to clean the paths up
so things fit on a reasonable screen.
The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
I tested locally that both checks give the expected error if I
temporarily change the != to an =.
--HG--
extra : transplant_source : %01N%B9%8B%BC%1E%07%D6%AE%BA2%7B%87%FB%25Y%19%B6%A9%D3
The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
--HG--
extra : transplant_source : D%D3%FE%169%05%D0X%F3KK%17%9EW%88%BCs%9B%86%5D
It looks like overwriting AS here is not intentional. Before this patch,
it is impossible to override AS through mozconfig for anything that runs
past this stage in configure.
Some Android SDK installations do not have the zipalign program in
the same directory as other Android build tools. For example,
zipalign may be found in /build-tools/21.1.2 whereas the
rest of the build tools are in /build-tools/android-4.4.
Right now, if the LLVMCONFIG variable is not set in the .mozconfig, we
first look for the system default llvm-config and only then we ask clang
itself, which breaks building with the clang plugin if you make $CC and
$CXX point to a non-default clang binary. This patch fixes the issue
by reversing the search order.
--HG--
extra : rebase_source : 23ab716f4e220097e4c31092475dba769f4e7dfc
In certain configurations, in particular when installing the Android SDK
using HomeBrew, one sees a configuration with symlinks like:
[brian@brian-macbook git]$ ls -l /usr/local/Cellar/android-sdk/23.0.2/
total 72
...
lrwxr-xr-x 1 brian admin 38 Nov 14 16:39 platforms -> ../../../var/lib/android-sdk/platforms
...
drwxr-xr-x 26 brian admin 884 Nov 14 17:43 tools
In this case, we have
ANDROID_SDK=/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21.
It is an anti-pattern to use ANDORID_SDK/.. to find other paths in the
tree. This pattern is used in at least two places:
1) When we try to find
/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21/../../tools,
we end up in the /usr/local/var/lib subtree. This patch works around
that by exporting and using ANDROID_TOOLS; ANDROID_TOOLS itself is
extracted using path matching, rather than following .. through the
filesystem.
2) We also need to use ANDROID_SDK_ROOT rather than
ANDROID_SDK/../.. through-out.
--HG--
extra : rebase_source : 5e0323a94f2b80550f17a624e16f338cdeec406d
On automation, this brings Windows configure time on a clobber from 5:30 to 3:10.
Sadly, because make needs to run under intl/icu/host before configuring
intl/icu/target, intl/icu/host needs to be configured independently. Fortunately,
that's not configured for normal windows builds anyways.
Also, having multiple subconfigures sharing the same cache file is dangerously
racy. Fortunately, not a lot do. In fact, only js/src and $_subconfigure_subdir
do, so force the latter (only used for ldap sdk on comm-central) not to
configure in parallel.
This saves dexing and shipping the Google Play Services and other Google
libraries, which add resources and about 3megs of code.
Due to ordering issues, the relevant flags and toggles were moved to
configure.in and exposed early enough to be used by confvars.sh.
While bug 903369 added some kind of wrapping, msys mangling on Windows made
it hard to make the python wrapper invoke subconfigures itself. This change
overcomes this, allowing to run subconfigures entirely independently of
the main configure if necessary, or to do more fancy checks without having
to resort to m4 and shell.
All subconfigures are essentially doing it already, so just inverse the process. That would also limit problems with additional subconfigures (all the recent ones had to come with their own config.cache)
This adds a format option to mach environment and uses it in client.mk to
create a .mozconfig.json in the objdir, containing all the relevant data
from mozconfig. If the mozconfig doesn't change in a way that alters that
data, we still skip configure.
At the same time, use mach environment in place of mozconfig2configure and
mozconfig2client-mk, which makes us now have only one mozconfig reader.
Also, in the mozconfig reader, keep track of environment variables (as
opposed to shell variables), so that changes such as a variable that was
exported not being exported anymore is spotted. At the opposite, in order
for irrelevant environment variable changes not to incur in re-running
configure, only a set of environment variables are stored when they are
unmodified. Otherwise, changes such as using a different terminal window,
or even rebooting, would trigger reconfigures.
Finally, make mach environment emit both MOZ_OBJDIR and OBJDIR for
client.mk, and cleanup some objdir-related things in client.mk..
At the same time, make the mozconfig reader take MOZ_OBJDIR from the
environment if it is defined there and not in the mozconfig.
CLOSED TREE (but for the commit above this because the commit hook only
appears to look at the tip commit)
--HG--
extra : rebase_source : c88e7e3f4d24dcd59a1a0b5577e3a77da68f3d08
extra : amend_source : 5be936181048b01850e9ef91c25fa0c7363d118d
This patch does two things: 1. Treat clang on Windows explicitly as MSVC. There
are some places in our build system where we try to detect clang by looking at
the output of $(CC) -v, and that will cause us to believe that we are using
clang, which is not helpful. This patch defines the CLANG_CL variable when it
detects clang being used on Windows. It also masquarades clang-cl as MSVC
2012, which is how the compiler introduces itself through the _MSC_VER
predefined variable.
2. Disable a bunch of things which currently are not supported on clang-cl. As
we proceed with this port, hopefully we'll be able to remove everything in this
list, but this will get us closer to be able to build with clang-cl.
With this patch and clang-cl trunk, we can get past the configure stage of the
build.
--HG--
extra : rebase_source : e5b8d77e4571c936820cec858953d58b6f31e0d5
This lists the directories in build-tools/*, sorts them by
version (favouring new-style 'android-*' directories), and then takes
the newest version in which aapt exists.
Before, we would run configure in both top-level and js/src, and both
configures would traverse their own set of moz.builds, without actual
knowledge about the other. With this change, both configures still run,
but only top-level traverses moz.build files, and uses js/src's
config.status when traversing its moz.build files. This allows a better
sharing of information between both build systems and the removal of many
hacks.
This also moves running libffi and icu configure to top-level.
Standalone js builds still have their own configure doing moz.build traversal,
as before.
--HG--
rename : config/autoconf.mk.in => config/autoconf-js.mk.in
rename : config/emptyvars.mk.in => config/emptyvars-js.mk.in
We happen to be lucky currently because e.g. build is created by config.status
before we subconfigure in build/clang-plugin. But further changes break that
luck.
This patch also tries to verify that the tools are actually found
early in the configure process, rather than failing with difficult to
parse errors at the end of the build.
Since the Android developer tools are defined earlier in the build
process, we can remove a work-around needed for |make install|.
MOZ_COMPILER_OPTS depends on MOZ_DEBUG_FLAGS being set for proper checking of
linker dead code deletion when using GCC.
GC'ing sections saves ~1.5MB off of mobile libxul according to size(1):
[froydnj@cerebro eideticker]$ size /opt/build/froydnj/build-android/dist/bin/libxul.so
text data bss dec hex filename
23733400 2314816 1495973 27544189 1a44a7d /opt/build/froydnj/build-android/dist/bin/libxul.so
[froydnj@cerebro eideticker]$ size /opt/build/froydnj/build-android/dist/bin/libxul.so
text data bss dec hex filename
22261936 2145116 1494533 25901585 18b3a11 /opt/build/froydnj/build-android/dist/bin/libxul.so
There were merges in configure.in and some Makefile.in. None had any
conflicts. I spot verified the Makefile.in changes and confirmed that
the changes did not touch any DIRS* variables.
Python and virtualenv logic is now contained within an m4 file.
SpiderMonkey now requires the mozilla-central virtualenv environment to
build. If SpiderMonkey configure is invoked by mozilla-central's
configure, the virtualenv will be reused. If SpiderMonkey configure is
invoked in isolation, it will search for the virtualenv in the
mozilla-central root.
* For android-ndk versions r7, r7b, r8, r8b
* std::ifstream broken in earlier versions of ndk
* ... used in jscntxt.cpp by ComputeIsJITBroken()
* Default gnu_compiler_version is 4.4.3
* If android_toolchain is not set, attempt to infer it from gnu_compiler_version.
* Copy changes from js/src/build/autoconf/android.m4 to build/autoconf/android.m4
1. mozconfig2client-mk still refers to $HOME/.mozconfig, even though we
removed it a while ago. Thanks to Neil for pointing it out.
2. MOZCONFIG_FIND and MOZCONFIG_MODULES are no longer used by client.mk.
3. Make CONFIG_GUESS a script that runs just once per client.mk invocation.
--HG--
extra : rebase_source : ec75ebcc5cea004f64abafb8a219e828234237de
Terrence Cole
Sebastian Kaspari
Mike Hommey
Carsten "Tomcat" Book
Ehsan Akhgari
Nick Alexander
Samael Wang
Ted Clancy
Nathan Froyd
Jacek Caban
Ted Mielczarek
James Willcox
Juan Gomez
ISHIKAWA, Chiaki
Makoto Kato
ijdt.editor@gmail.com
Hector Zhao
L. David Baron
Bob Owen
Akos Kiss
Abhishek Bhattacharya
Trevor Saunders
Ryan VanderMeulen
Ms2ger
Jed Davis
Georg Koppen
Tooru Fujisawa
Ian Neal
Ed Morley
Jim Chen
Christian Holler
Richard Newman
Nathan Toone
Wes Kocher
Jan de Mooij
Steve Fink
Joshua Cranmer
Tim Taubert
Brian R. Bondy
Birunthan Mohanathas
Wes Johnston
Henri Sivonen
Brad Lassey
Andrew McCreight
Ulrich Weigand
Phil Ringnalda
Landry Breuil
Mike Shal
Jan Beich
James Gilbertson
Chris Kitching
retornam
Gregory Szorc
Vladimir Vukicevic
Panos Astithas
Dan Gohman
Doug Turner
Irving Reid
JW Wang
Jeff Muizelaar
Roberta De Viti
Nathan Froyd
Chris Peterson
Gian-Carlo Pascutto
Vicamo Yang
Kyle Huey
Paul Adenot
Felix S. Klock II
Kartikaya Gupta
Surith Thekkiam
Rafael Ávila de Espíndola
Aryeh Gregor
Siddharth Agarwal
Masatoshi Kimura