1174757 - [geckoview] Default GeckoView build flag to off locally

Status: RESOLVED DUPLICATE of bug 1212347

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

Description

[Nick Alexander :nalexander [he/him]]

We should flip the GeckoView build flag so that by default GV is only built on the builders.

We have very few local conflicts (since GV is basically Fennec); GV building is slow during packaging; and we see terrible errors like https://code.google.com/p/android/issues/detail?id=176488 that we have little chance to address.

Comment 1

[Nick Alexander :nalexander [he/him]]

The relevant build flag is MOZ_DISABLE_GECKOVIEW.  I suggest we flip that to MOZ_PACKAGE_GECKOVIEW or similar and /enable/ it in automation, rather than disable it.

https://dxr.mozilla.org/mozilla-central/search?q=MOZ_DISABLE_GECKOVIEW&case=true&redirect=true

Comment 2

[Richard Newman [:rnewman]]

Attachment: Only build GeckoView for API11+ Nightly. v1

Untested. N.B., we only ever build GV if NIGHTLY_BUILD is set anyway, so no point touching other mozconfigs, no?

Comment 3

[Mike Hommey [:glandium]]

When I mentioned doing this a while ago, someone made the case that this was needed on local builds because it was easy to break without knowing before landing. Isn't this true anymore?

Comment 4

[Nick Alexander :nalexander [he/him]]

(In reply to Mike Hommey [:glandium] from comment #3)
> When I mentioned doing this a while ago, someone made the case that this was
> needed on local builds because it was easy to break without knowing before
> landing. Isn't this true anymore?

I don't think it's true anymore.  That might have been blassey?

Comment 5

[Mike Hommey [:glandium]]

It was probably blassey or mfinkle.

Comment 6

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Nick Alexander :nalexander from comment #4)
> (In reply to Mike Hommey [:glandium] from comment #3)
> > When I mentioned doing this a while ago, someone made the case that this was
> > needed on local builds because it was easy to break without knowing before
> > landing. Isn't this true anymore?
> 
> I don't think it's true anymore.  That might have been blassey?

why would this not be true anymore?

Comment 7

[Nick Alexander :nalexander [he/him]]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #6)
> (In reply to Nick Alexander :nalexander from comment #4)
> > (In reply to Mike Hommey [:glandium] from comment #3)
> > > When I mentioned doing this a while ago, someone made the case that this was
> > > needed on local builds because it was easy to break without knowing before
> > > landing. Isn't this true anymore?
> > 
> > I don't think it's true anymore.  That might have been blassey?
> 
> why would this not be true anymore?

The GeckoView packaging has not been fragile, to the best of my knowledge, for a long time.  The amount of churn in the build system is low.

Local developers are spending a lot of time, including dealing with tools failures that we can't really work-around, packaging a thing that gets minimal usage.

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

Sadly, we have GeckoView bustage right now. I had to manually patch my Android SDK top be able to build/package GeckoView. The builders don't seem to have the problem. Does that mean we are still catching GeckoView bustage on TBPL?

Comment 9

[Nick Alexander :nalexander [he/him]]

(In reply to Mark Finkle (:mfinkle) from comment #8)
> Sadly, we have GeckoView bustage right now. I had to manually patch my
> Android SDK top be able to build/package GeckoView. The builders don't seem
> to have the problem. Does that mean we are still catching GeckoView bustage
> on TBPL?

We have a weak combination: we catch build time bustage -- really only /package time/ bustage -- on TBPL; and we catch no run-time bustage.  I have been pushing Geckoview AARs to TBPL for a while; it wouldn't be too hard to run a CI or Travis Gradle job that interates against those AARs and actually runs a test suite.

Comment 10

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8622525 [details] [diff] [review]
Only build GeckoView for API11+ Nightly. v1

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

Passing on this for now.  Sounds like some work is still needed.

Comment 11

[Nick Alexander :nalexander [he/him]]

Attachment: MozReview Request: Bug 1174757 - Pre: Don't archive geckoview resources when not necessary. r=glandium

Bug 1174757 - Pre: Don't archive geckoview resources when not necessary. r=glandium

This is a small optimization that will also make it easier to flip the
MOZ_DISABLE_GECKOVIEW conditional.  We don't currently package
geckolibs without geckoview, and it's reasonable to do both if we want
one.

Comment 12

[Mike Hommey [:glandium]]

Comment on attachment 8626384 [details]
MozReview Request: Bug 1174757 - Pre: Don't archive geckoview resources when not necessary. r=glandium

https://reviewboard.mozilla.org/r/12083/#review10713

Ship It!

Comment 13

[Nick Alexander :nalexander [he/him]]

https://hg.mozilla.org/integration/fx-team/rev/3d97c78ff336

Comment 14

[Nick Alexander :nalexander [he/him]]

Pushed the pre.

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/3d97c78ff336

Comment 16

[:Margaret Leibovic]

I'm not a huge fan of leave-open bugs, especially if they haven't been touched in months. Can we close this and file new bugs for the necessary follow-up work?

Comment 17

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Disabling the GV build is replaced by bug 1212347, so if it's just that, it can be duped.

Nick, what else is there to do here?

Comment 18

[Nick Alexander :nalexander [he/him]]

(In reply to Michael Comella (:mcomella) from comment #17)
> Disabling the GV build is replaced by bug 1212347, so if it's just that, it
> can be duped.
> 
> Nick, what else is there to do here?

Nothing.  Somebody (possibly future me) can try to make GV better (perhaps post Gradle builds), and re-implement GVE at that time.

Comment 19

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Sounds like those can be a follow-ups if we decide to do them.

Comment 20

[Firefox Bug Husbandry Bot]

Removing leave-open keyword from resolved bugs, per :sylvestre.