950676 - Bring back b2g unified builds

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[(no longer active)]

Follow-up from bug 946576 comment 11.

glandium, can you take this please?

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

please! I would like fast B2G builds.

Comment 2

[Mike Hommey [:glandium]]

(In reply to Benoit Jacob [:bjacob] from comment #1)
> please! I would like fast B2G builds.

You know you can change your mozconfig, right?

Comment 3

[(no longer active)]

(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?

Comment 4

[[:fabrice] Fabrice Desré]

(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

Comment 5

[(no longer active)]

(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. :(

Comment 6

[Benoit Girard (:BenWa)]

Are we just missing a flip? B2G builds are significantly slower.

Comment 7

[(no longer active)]

(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...

Comment 8

[Mike Hommey [:glandium]]

We still don't have b2g non-unified builds on tbpl, do we?

Comment 9

[(no longer active)]

(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?

Comment 10

[Mike Hommey [:glandium]]

I'm not the best person for b2g build system problems. Try needinfo'ing mwu on the relevant bug.

Comment 11

[(no longer active)]

Attachment: Patch (v1)

With the work done in bug 942167, we now just need to remove this line!

Comment 12

[Mike Hommey [:glandium]]

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.

Comment 13

[(no longer active)]

(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...

Comment 14

[(no longer active)]

https://hg.mozilla.org/integration/b2g-inbound/rev/3cde3e356720

Comment 15

[Mike Hommey [:glandium]]

(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.

Comment 16

[Gregor Wagner [:gwagner]]

Backout for compile errors:
https://hg.mozilla.org/integration/b2g-inbound/rev/1ee6beefbe27

Comment 17

[(no longer active)]

(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.

Comment 18

[(no longer active)]

(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

Comment 19

[Mike Hommey [:glandium]]

(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.

Comment 20

[(no longer active)]

(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.

Comment 21

[(no longer active)]

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.)

Comment 22

[Mike Hommey [:glandium]]

> 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.

Comment 23

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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.

Comment 24

[(no longer active)]

(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.

Comment 25

[(no longer active)]

(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

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/4f88707d2c7f