Open Bug 1509539 Opened 4 years ago Updated 1 year ago
Add gradle support for building gecko binaries
+++ 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.
No longer depends on: 1418464
Depends on: 1418464
Depends on: 1509572
Depends on: 1509573
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
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
You need to log in before you can comment on or make changes to this bug.