Trying to build current inbound on OS X after updating to SDK including 4.3, build fails

RESOLVED FIXED in Firefox 25

Status

()

Firefox for Android
General
--
major
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: MarcoZ, Assigned: nalexander)

Tracking

Trunk
Firefox 25
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
The build attempt fails with these errors:


make[6]: /Users/marcozehe/android-sdk-macosx/platforms/android-16/../../platform-tools/aapt: No such file or directory
make[6]: *** [sutAgentAndroid.ap_] Error 1
make[6]: *** Waiting for unfinished jobs....
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
make[6]: /Users/marcozehe/android-sdk-macosx/platforms/android-16/../../platform-tools/dx: No such file or directory
make[6]: *** [classes.dex] Error 1

All these files have moved to the build-tools folder instead of platform-tools.

Note that Android SDK was simply updated, not reinstalled.
(Assignee)

Updated

5 years ago
Assignee: nobody → nalexander
(Assignee)

Comment 1

5 years ago
Do you have additional input on the new directory structure, mcomella?
Flags: needinfo?(michael.l.comella)
(Assignee)

Comment 2

5 years ago
Created attachment 781932 [details] [diff] [review]
Search for Android SDK build tools version 18.0.0. r=gps

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

Open question: there are no external users of ANDROID_*TOOLS.  Should
I remove these three AC_SUBST invocations, or should they remain in?
Attachment #781932 - Flags: review?(gps)
(Assignee)

Comment 3

5 years ago
> Open question: there are no external users of ANDROID_*TOOLS.  Should
> I remove these three AC_SUBST invocations, or should they remain in?

Second open question: clobber needed?
Flags: needinfo?(marco.zehe)
(Assignee)

Comment 4

5 years ago
Marco, can you see if this addresses your issue?  I'm not clear on how upgrading factors into what your seeing.  I have tried to improve the error messaging during configure to avoid your error.
Adding the hardcoded version numbers like you did in the patch seems the safest approach to me (for fear of any tools being removed or significantly changed in later revisions), though I am curious why  .../build-tools/android-4.2.2 is one of the options for the paths (I have only seen 17.0.0 and 18.0.0).

Otherwise, let me know if there's any more specific feedback you were looking for.
Flags: needinfo?(michael.l.comella)
Also, untested workaround: You should still be able to use the android utility to download build-tools rev. 17, which the build system expects to find and thus should build successfully.

Comment 8

5 years ago
Comment on attachment 781932 [details] [diff] [review]
Search for Android SDK build tools version 18.0.0. r=gps

Review of attachment 781932 [details] [diff] [review]:
-----------------------------------------------------------------

If there are no users of the ANDROID_*TOOLS variables, by all means remove them from AC_SUBST and/or AC_DEFINE! Pollution is bad for the environment.

I'm requesting additional review because my M4 skills are teh suck and glandium always finds things I don't.

I'm still not fully on top of all the Android packages and versions. It seems to me that listing 18.0.0 in android.m4 is effectively saying we now support this whole new version of something and that isn't a trivial change to make! From my limited experience with Android development, I know you can have multiple versions of the SDK installed at once. Why won't that work here? Must we support version 18.0.0 explicitly? Can a user not continue to use version 17.0.0? If they can use 17.0.0, why are we now supporting 18.0.0? What testing has been performed to ensure compatibility?

::: build/autoconf/android.m4
@@ +332,5 @@
> +    MOZ_PATH_PROG(ADB, adb, :, [$ANDROID_PLATFORM_TOOLS])
> +
> +    if test -z "$ZIPALIGN" -o "$ZIPALIGN" = ":"; then
> +      AC_MSG_ERROR([The program zipalign was not found.  Use --with-android-sdk={android-sdk-dir}.])
> +    fi

I thought MOZ_PATH_PROG or some other macro enforced that a program was present.
Attachment #781932 - Flags: review?(mh+mozilla)
Attachment #781932 - Flags: review?(gps)
Attachment #781932 - Flags: review+
(Assignee)

Comment 9

5 years ago
> I'm still not fully on top of all the Android packages and versions. It
> seems to me that listing 18.0.0 in android.m4 is effectively saying we now
> support this whole new version of something and that isn't a trivial change
> to make! From my limited experience with Android development, I know you can
> have multiple versions of the SDK installed at once. Why won't that work
> here? Must we support version 18.0.0 explicitly? Can a user not continue to
> use version 17.0.0? If they can use 17.0.0, why are we now supporting
> 18.0.0? What testing has been performed to ensure compatibility?

Adding 18.0.0 to the list says that we're okay with using the new versions of the Android build tools, not that we support the Android 18 platform.  (That's controlled by the manifests.)  It's like supporting a new version of gcc, which I agree is a big deal.  I've done no compatibility testing, but in my experience, the Android tools like dx, adb, and aapt have not caused compatibility problems.  (I do imagine the Android gcc and ld toolchains have caused problems, but this change doesn't affect that part of the tooling.)

I personally support this because the |android| tool defaults to installing the latest build tools, and I see no reason to not support the default.  But a user can continue to use version 17 build tools without difficult.  When I upgraded, the 17.0.0 build tools remained; I have already asked Marco for information about his upgrade.

mfinkle, blassey: any reason to not enable building with the SDK 18 build tools?
Flags: needinfo?(mark.finkle)
Flags: needinfo?(blassey.bugs)
I'm OK with allowing devs to try newer versions of the SDK. This won't affect the current releng/tbpl builds.

This might make it easier for people to find and fix issues with newer SDKs, before we consider making them mainline.
Flags: needinfo?(mark.finkle)
(In reply to Mark Finkle (:mfinkle) from comment #10)
> I'm OK with allowing devs to try newer versions of the SDK. This won't
> affect the current releng/tbpl builds.
> 
> This might make it easier for people to find and fix issues with newer SDKs,
> before we consider making them mainline.

Not necessarily. Unless certain variables are set (which they may be today but you can never guarantee for all of time), configure will choose the first discovered environment. Since 18.0.0 is listed before 17.0.0, it will choose 18.0.0 if it is available.

I'd feel much better if we listed the preferred version(s) first and non-preferred-but-still-supported versions after. I'd feel even better if we didn't list non-preferred versions at all and were more strict about our build requirements. Can we not add Android support to the build environment bootstrapper (/python/mozboot)?
(Assignee)

Comment 12

5 years ago
(In reply to Gregory Szorc [:gps] from comment #11)
> (In reply to Mark Finkle (:mfinkle) from comment #10)
> > I'm OK with allowing devs to try newer versions of the SDK. This won't
> > affect the current releng/tbpl builds.
> > 
> > This might make it easier for people to find and fix issues with newer SDKs,
> > before we consider making them mainline.
> 
> Not necessarily. Unless certain variables are set (which they may be today
> but you can never guarantee for all of time), configure will choose the
> first discovered environment. Since 18.0.0 is listed before 17.0.0, it will
> choose 18.0.0 if it is available.
> 
> I'd feel much better if we listed the preferred version(s) first and
> non-preferred-but-still-supported versions after. I'd feel even better if we
> didn't list non-preferred versions at all and were more strict about our
> build requirements. Can we not add Android support to the build environment
> bootstrapper (/python/mozboot)?

Listing 18.0.0 first was intentional; if you've installed a newer version, presumably you want to use it.  We don't support setting the various ANDROID_*_TOOLS paths independently (and I don't think we should), so we do have to set an order here.  Both mfinkle and I agree that the newer version should be preferred.  I suggest we let blassey weigh in and if he concurs then we deal with any future 18 vs 17 fallout by changing the list entirely or the relative order.

If that's unacceptable, I suggest we break this into two pieces.  Let's land the error reporting parts (which will tell people during configure if the tools couldn't be found, with a clear(ish) error message) immediately, and then discuss whether and where to add 18.0.0 to the supported tools list.  Reasonable?

Finally, as for Android support to mozboot, I see no reason it could not be added.  But I don't know what the bootstrapper is, or how it fits into the configure process.
Flags: needinfo?(gps)
Attachment #781932 - Flags: review?(mh+mozilla) → review+
(Reporter)

Comment 13

5 years ago
I just completed a build with this patch applied. Works for me!
Flags: needinfo?(marco.zehe)
no objection as long as it doesn't break anything existing
Flags: needinfo?(blassey.bugs)
(Assignee)

Comment 15

5 years ago
> I thought MOZ_PATH_PROG or some other macro enforced that a program was
> present.

Unfortunately not.  It sets the result if the program exists, but it's up to the caller to error.

http://mxr.mozilla.org/mozilla-central/source/build/autoconf/mozprog.m4#21
You have r+ from me.

I would prefer to keep the number of supported build configurations low, otherwise we end up chasing compatibility with old, deprecated versions. Please file followups to ensure 18.0.0 is deployed on Release Engineering infrastructure and to remove support for 17.0.0 once our infra is building with 18.0.0.

Is that fair?
Flags: needinfo?(gps)
(Assignee)

Comment 17

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/db8581f995e9
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 25
(Assignee)

Comment 18

5 years ago
(In reply to Gregory Szorc [:gps] from comment #16)
> You have r+ from me.
> 
> I would prefer to keep the number of supported build configurations low,
> otherwise we end up chasing compatibility with old, deprecated versions.
> Please file followups to ensure 18.0.0 is deployed on Release Engineering
> infrastructure and to remove support for 17.0.0 once our infra is building
> with 18.0.0.

Filed Bug 889616 to upgrade the buildbots to 18.0.0, and filed Bug 899618 to remove support for 17.0.0.  Thanks for quick review!
https://hg.mozilla.org/mozilla-central/rev/db8581f995e9
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.