We try to generate a C++ constant for static final fields, but that
was failing for inaccessible fields. Now we set the field to be
accessible so that we do end up generating a C++ constant.
Right now, when we generate bindings for Java class A, and we encounter
a Java type B, we generate a corresponding C++ name only if A == B,
otherwise we generate a generic "jni::Object" C++ name. For example,
class Foo {
class Bar {
Foo getFoo(Bar bar);
}
}
In C++, Foo.Bar.getFoo would become,
class Foo {
class Bar {
jni::Object::LocalRef getFoo(Bar::Param bar);
};
};
This patch extends the code generator so that any Java class in the
chain of declared classes gets a corresponding C++ name. The above
example now becomes,
class Foo {
class Bar {
Foo::LocalRef getFoo(Bar::Param bar);
};
};
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
This adds a stages config option, which can be used to select 1, 2, and
3 stage builds. It also marks the default trunk configuration to do 3
stage builds, and defaults to that.
Since CMake generated build systems can run cmake if necessary, this
will make it possible to pick up changes from the source directory if
any and resume as much of the build as possible.
This builds the foundation for removing the need to blow away any of the
work done by the previous runs of the script.
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
