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 patch allows you to set MOZ_APP_ANDROID_VERSION_CODE in a branding's configure.sh to specify the exact android:versionCode to use in the final (main) APK. It does *not* modify the android:versionCode used in any other APKs.
Even though we compile C code as C99, we used to need
-Wdeclaration-after-statement because MSVC didn't allow declarations after
statements.
However, Visual Studio 2013 added support, so we can now merrily mix
declarations and statements everywhere. Hooray.
This warning is typically triggered by code which implements
some kind of assertion macro, and it's probably not a good
indicator of bugs anyway, so there is no good reason to keep
it on.
Currently, all versions of Firefox run with the existing native
Firefox Account UI. This flag will opt-in to maintaining that
experience while we transition to a web account UI. Once we're stable
on the web, we'll remove this flag entirely.
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.
qcms and libav use __attribute__((force_align_arg_pointer))
unconditionally; the libav use case suggests that the attribute has been
around since GCC 4.2. We're well past that point with GCC, and clang
supports it also. So we can simply assume the compiler has it in the
appropriate places.
It is, however, x86 only (x86-64 appropriately aligns the stack at all
times), so we need to adjust the libpixman build code appropriately.
<sys/int_types.h> appears to be a pre-standardization header that was
common on SunOS systems (which apparently also provided <inttypes.h>?).
Searching also turns up references in the NetBSD source tree for
less-common architectures (e.g. sh3). There are a few includes for
<sys/int_types.h> in the tree, but only as a fallback for <inttypes.h>.
In short, we don't care about this header, and we shouldn't check for it.
We appear to be inconsistent about which CFLAGS variables get
substituted as lists (most things relating to widget libraries, for
instance) and which are just raw strings (most everything else). This
patch is a first step towards making everything a list, which makes the
next patch much easier to write. The other variables can be converted
as a followup bug.
