Closed Bug 1093242 Opened 9 years ago Closed 9 years ago

Produce and upload AAR file containing built binaries during packaging

Categories

(Firefox Build System :: General, defect)

All
Android
defect
Not set
normal

Tracking

(firefox38 fixed)

RESOLVED FIXED
mozilla38
Tracking Status
firefox38 --- fixed

People

(Reporter: nalexander, Assigned: nalexander)

References

Details

Attachments

(1 file, 1 obsolete file)

As a first step towards building Fennec without requiring compiling the C++ binaries layer first, I'd like to find a way to move the "binaries" things that Fennec depends on earlier in the build process.

At the moment, mobile/android ignores binaries and then they are shoved into the APK at package time.  In fact, all the binaries are built and assembled into libraries before we build mobile/android.  (There is one tricky thing that we 7zip libs at package time rather than build time.)

That gets in the way of building with IDEs, where libraries are a pre-requisite and are packed into the APK early on.

I would like to make the binaries a dependency of mobile/android.  The blessed format for Android dependencies is AAR, so what I envision is that a Gradle project rooted in mobile/android would reference a dependency like:

org.mozilla.binaries:aar:$BUILDID

where $BUILDID is some identifier for the set of built binaries.  In the interim, the packager might continue to pull the binaries from said AAR file at package time.
glandium: do you have thoughts on this?  Can you suggest a good place -- before the mobile/android libs tier but after all the binaries have been produced -- to create such an AAR?

Can you suggest what a good BUILDID would be?  Is the actual build ID that we shove into the APK and JSON metadata the right thing to use?  Would a "latest" (SNAPSHOT in Maven parlance, I think) identifier be the best option?
We probably want to arrange for architecture specific assets to be in architecture dependent directories before this: Bug 976699.
Blocks: 976699
Flagging ckitching 'cuz this is relevant to Gradle/IntelliJ and st3fan because this is a step towards consuming Java artifacts as suggested in your mobile-firefox (private) mailing list post.
/r/3899 - Bug 1093242 - Produce and upload geckolibs artifacts for Android API v11+ opt builds. r=gps

Pull down this commit:

hg pull review -r 1549adaa3ec63936fef0c0b57c56d033a6e6f1bb
Attachment #8564857 - Flags: review?(gps)
https://reviewboard.mozilla.org/r/3897/#review3083

I modeled this after Bug 1051809, which uploads code coverage files.  I really do want this only for Android ARMv7 opt builds, API 11+.
https://reviewboard.mozilla.org/r/3899/#review3133

Fix the issue and resubmit for review to hopefully get a quick rubber stamp.

::: python/mozbuild/mozbuild/action/package_geckolibs_aar.py
(Diff revision 1)
> +    from buildconfig import topsrcdir, topobjdir

I hate the buildconfig module with passion. Can you pass these variables in?
Comment on attachment 8564857 [details]
MozReview Request: bz://1093242/nalexander

/r/3899 - Bug 1093242 - Produce and upload geckolibs artifacts for Android API v11+ opt builds. r=gps

Pull down this commit:

hg pull review -r 0c12b44f587d4a027ca5258bae8fcbb6f6028c24
Comment on attachment 8564857 [details]
MozReview Request: bz://1093242/nalexander

https://reviewboard.mozilla.org/r/3897/#review3261

Ship It!
Attachment #8564857 - Flags: review?(gps) → review+
I morphed this ticket into something a little different.  This produces and uploads a "geckolibs" AAR and accompanying metadata, but does not consume it locally.
Assignee: nobody → nalexander
Status: NEW → ASSIGNED
Summary: Produce AAR file containing built binaries before building mobile/android → Produce and upload AAR file containing built binaries during packaging
(In reply to Nick Alexander :nalexander from comment #14)
> I morphed this ticket into something a little different.  This produces and
> uploads a "geckolibs" AAR and accompanying metadata, but does not consume it
> locally.

Is there a bug logged for consuming the libraries?  If be interested in following the status of that one as well.
Blocks: 927388
Attachment #8564857 - Attachment is obsolete: true
Attachment #8618543 - Flags: review+
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.