Open Bug 1509539 Opened 6 years ago Updated 2 years ago

Add gradle support for building gecko binaries

Categories

(Firefox Build System :: Android Studio and Gradle Integration, enhancement, P3)

Product:
Firefox Build System
Component:
Android Studio and Gradle Integration
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: nalexander, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(4 obsolete files)

+++ This bug was initially created as a clone of Bug #1418464 +++ I accidentally stole Bug 1418464 for just a piece of this work, so I'm cloning and updating that description: It's nice that we have an Android Studio project that allow us to build geckoview_example and geckoview, but it would be nice if hitting the 'run' button would also bring in any changes to gecko itself. The workflow is basically: 1) Add a new method to GeckoView 2) Implement above method in Gecko using JS or native code 3) Write a test or new API in GeckoViewExample or other sibling project 4) Win Since setting up a gecko build is such an involved process I think we could just punt on that. We'd probably just assume that 'mach build && mach package' works. I don't think we really want Studio to install a mozconfig, for instance. The instructions for getting this to work for developers would basically be 'mach bootstrap', set up mozconfig, then ensure 'mach configure' works.
This is tricky because there's a dependency chain: mach stage-package (building the omnijar) depends on mach build binaries (building libxul.so) depends on generating JNI wrappers depends on compiling Java Now, in Bug 1444546 we moved the JNI wrapper generation into the Gradle build, and we made a JNI wrapper generating task for each variant. That's a problem because there really is only one JNI wrapper generation option -- whatever is invoked as part of |mach build| -- and because the proliferation of tasks makes |mach stage-package| depend on lots of _different_ compiling Java tasks (duplicating tons of work and slowing builds down significantly). This ticket narrows us down to two JNI wrapper generating tasks. The task names are complicated in order to not change too many things. Depends on D12799
This is just the mechanics of dropping the flavor -- no real consideration for whether it works yet. These parts will all be folded before landing. Depends on D12800
Attached file Bug 1509539 - Part 1c: Update automation. r?snorp (obsolete) (deleted) —
Again, these will all be folded together. Depends on D12801
This commit is the meat of the series. (Remember, the series will all land together; the parts are just for ease of reviewing.) This moves the "with/without" Gecko binaries logic to depend on the actual tasks invoked by Gradle. If we are asked to `assemble` GeckoView or Fennec (and we're not in the special circumstance of |mach build|), then we are in the "withGeckoBinaries" flow: - We invoke |mach build binaries| if COMPILE_ENVIRONMENT - We invoke |make -C ... stage-package| - We copy omni.ja and libs/ into place for the Android-Gradle AAR/APK packager If we're not asked to `assemble` (or if we're under |mach build|, then we don't do any of that. We leave any omni.ja and libs/ in place, but we don't require them. If we get everything right, this somewhat transparently work the moz.build system into the Gradle build system when it's required. I'm sure there will be issues, but we can start from this and work out problems as they become clear. Depends on D12802

There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:nalexander, could you have a look please?

Flags: needinfo?(nalexander)
Depends on: 1540820
Product: Firefox for Android → Firefox Build System

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #5)

There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:nalexander, could you have a look please?

Just circling back: this will take a different direction at some point, post Bug 1550146. snorp is actively looking at removing withGeckoBinaries, following these patches.

Flags: needinfo?(nalexander)

Note to self: moons ago, I worked out an approach for getting rid of withGeckoBinaries. That's in the patch series here. It's sneaky: it uses the Gradle task graph to determine if the Gecko binaries (libxul.so and friends, omni.ja) are needed.

But the moon has moved, and I think this sneakiness might not be necessary. The signal that Gecko binaries are needed should just be COMPILE_ENVIRONMENT || MOZ_ARTIFACT_BUILDS. If I'm correct, we could dramatically simplify this situation by using that as the conditional rather than having the geckoBinaries product flavour dimension.

Attachment #9027273 - Attachment is obsolete: true
Attachment #9027274 - Attachment is obsolete: true
Attachment #9027275 - Attachment is obsolete: true
Attachment #9027276 - Attachment is obsolete: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: