Closed Bug 950676 Opened 7 years ago Closed 6 years ago

Bring back b2g unified builds

Categories

(Firefox Build System :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla33

People

(Reporter: ehsan, Assigned: ehsan)

References

Details

Attachments

(1 file)

Follow-up from bug 946576 comment 11.

glandium, can you take this please?
please! I would like fast B2G builds.
(In reply to Benoit Jacob [:bjacob] from comment #1)
> please! I would like fast B2G builds.

You know you can change your mozconfig, right?
(In reply to comment #2)
> (In reply to Benoit Jacob [:bjacob] from comment #1)
> > please! I would like fast B2G builds.
> 
> You know you can change your mozconfig, right?

Isn't that mozconfig baked into the b2g build system?
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #3)
> (In reply to comment #2)
> > (In reply to Benoit Jacob [:bjacob] from comment #1)
> > > please! I would like fast B2G builds.
> > 
> > You know you can change your mozconfig, right?
> 
> Isn't that mozconfig baked into the b2g build system?

for device builds, it's at $B2G/gonk-misc/default-gecko-config
(In reply to comment #4)
> (In reply to :Ehsan Akhgari (needinfo? me!) from comment #3)
> > (In reply to comment #2)
> > > (In reply to Benoit Jacob [:bjacob] from comment #1)
> > > > please! I would like fast B2G builds.
> > > 
> > > You know you can change your mozconfig, right?
> > 
> > Isn't that mozconfig baked into the b2g build system?
> 
> for device builds, it's at $B2G/gonk-misc/default-gecko-config

Right, so that means that developers need to modify their local gonk-misc checkouts.  That's not great. :(
Are we just missing a flip? B2G builds are significantly slower.
(In reply to Benoit Girard (:BenWa) from comment #6)
> Are we just missing a flip? B2G builds are significantly slower.

I'm not sure what needs to be done here...
Flags: needinfo?(mh+mozilla)
We still don't have b2g non-unified builds on tbpl, do we?
Flags: needinfo?(mh+mozilla)
(In reply to comment #8)
> We still don't have b2g non-unified builds on tbpl, do we?

We don't, but that's because we're stuck on a solution.  Can you please help us out?
I'm not the best person for b2g build system problems. Try needinfo'ing mwu on the relevant bug.
See Also: → 942167
Attached patch Patch (v1)Splinter Review
With the work done in bug 942167, we now just need to remove this line!
Assignee: nobody → ehsan
Attachment #8440924 - Flags: review?(mh+mozilla)
Comment on attachment 8440924 [details] [diff] [review]
Patch (v1)

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

Please file a bug for the remaining --disable-unified-compilation in other non-nonunified mozconfigs.
Attachment #8440924 - Flags: review?(mh+mozilla) → review+
(In reply to Mike Hommey [:glandium] from comment #12)
> Please file a bug for the remaining --disable-unified-compilation in other
> non-nonunified mozconfigs.

Hmm, you mean the one for xulrunner?  I believe the rest are intentionally there...
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #13)
> Hmm, you mean the one for xulrunner?  I believe the rest are intentionally
> there...

I'm talking about all of them. At least the linux one is useless. The android ones, might be necessary, but that needs to be proven.
(In reply to Mike Hommey [:glandium] from comment #15)
> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #13)
> > Hmm, you mean the one for xulrunner?  I believe the rest are intentionally
> > there...
> 
> I'm talking about all of them. At least the linux one is useless. The
> android ones, might be necessary, but that needs to be proven.

They are not useless.  Linux 32-bit and armv6/x86 Android and ASAN builds are platforms where we don't have coverage for non-unified builds on TBPL for (because of resource consumption reasons), so we decided to force all of those builds to be non-unified always.  I think the same goes for XULRunner but we never really cared about it much either way.
(In reply to Gregor Wagner [:gwagner] from comment #16)
> Backout for compile errors:
> https://hg.mozilla.org/integration/b2g-inbound/rev/1ee6beefbe27

Sorry, had to make one WebRTC file build as non-unified.  Retry: https://hg.mozilla.org/integration/b2g-inbound/rev/9c6b3b1f05ea
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #17)
> They are not useless.  Linux 32-bit and armv6/x86 Android and ASAN builds
> are platforms where we don't have coverage for non-unified builds on TBPL
> for (because of resource consumption reasons), so we decided to force all of
> those builds to be non-unified always.  I think the same goes for XULRunner
> but we never really cared about it much either way.

Linux 32 bits are very unlikely to break without the linux 64 bits builds breaking as well. If we *really* want to have non-unified coverage for them, we should set up periodic non-unified builds for them as well, instead of relying on linux 32-bits debug builds being non-unified (which makes those builds significantly slower). Same probably applies to Android. ASAN is a different story.
(In reply to comment #19)
> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #17)
> > They are not useless.  Linux 32-bit and armv6/x86 Android and ASAN builds
> > are platforms where we don't have coverage for non-unified builds on TBPL
> > for (because of resource consumption reasons), so we decided to force all of
> > those builds to be non-unified always.  I think the same goes for XULRunner
> > but we never really cared about it much either way.
> 
> Linux 32 bits are very unlikely to break without the linux 64 bits builds
> breaking as well. If we *really* want to have non-unified coverage for them, we
> should set up periodic non-unified builds for them as well, instead of relying
> on linux 32-bits debug builds being non-unified (which makes those builds
> significantly slower). Same probably applies to Android. ASAN is a different
> story.

Yes, I understand this.  What I'm saying is that we decided to not provide unified coverage for these builds on our infra, therefore we don't need specific non-unified coverage either.  Note that I don't really care much either way, this is just basically me and catlee trying to be cautious about our infra resource consumption.  If you want us to provide unified coverage for some of these platforms, please let me know which ones and I'll file the bugs, but I probably won't work on that myself.
This seems to have caused an intermittent test failure in canvas code :(
https://tbpl.mozilla.org/php/getParsedLog.php?id=41894617&tree=B2g-Inbound#error0

Backed out: https://hg.mozilla.org/integration/b2g-inbound/rev/86fb458dcc99

(Note that I left the WebRTC change in the tree.)
> this is just basically me and catlee trying to be cautious about our infra resource consumption

I'm pretty sure periodic non-unified builds take less infrastructure resources than the additional time spent by doing non-unified builds on every push.
So, the push with the backout has mochitest-4 running really green, but it's also green somewhere prior to the backout push: https://tbpl.mozilla.org/?tree=B2g-Inbound&jobname=b2g_emulator_vm%20b2g-inbound%20debug%20test%20mochitest-debug-4&rev=daa021be9c18

I have two more pushes that I'm retriggering m4 runs on to track down where it stopped failing, but I'm pretty sure it wasn't this patch at fault, so you should be clear to reland it whenever.
Flags: needinfo?(ehsan)
(In reply to Mike Hommey [:glandium] from comment #22)
> > this is just basically me and catlee trying to be cautious about our infra resource consumption
> 
> I'm pretty sure periodic non-unified builds take less infrastructure
> resources than the additional time spent by doing non-unified builds on
> every push.

OK let's take this to bug 942167.
(In reply to Wes Kocher (:KWierso) from comment #23)
> So, the push with the backout has mochitest-4 running really green, but it's
> also green somewhere prior to the backout push:
> https://tbpl.mozilla.org/?tree=B2g-Inbound&jobname=b2g_emulator_vm%20b2g-
> inbound%20debug%20test%20mochitest-debug-4&rev=daa021be9c18
> 
> I have two more pushes that I'm retriggering m4 runs on to track down where
> it stopped failing, but I'm pretty sure it wasn't this patch at fault, so
> you should be clear to reland it whenever.

Thanks, relanded!

https://hg.mozilla.org/integration/b2g-inbound/rev/4f88707d2c7f
Flags: needinfo?(ehsan)
https://hg.mozilla.org/mozilla-central/rev/4f88707d2c7f
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.