Sorry. To be clear: the (still existing) hazard builds *do* use the
emulator, which is at least half the reason why they're so difficult to
maintain and upgrade.
I don't know what the Gonk layer is exactly. I do know that there is
code in the gecko tree guarded by #ifdef MOZ_B2G_RIL, and I believe that
code is compiled by the same compiler that compiles the rest of gecko,
which is why the hazard analysis found bugs in it. There is other code
compiled when doing an emulator build that is compiled by a different
compiler, but it can't call the JSAPI directly or indirectly so I don't
care about it for the analysis. (The problems I ran into when I
attempted to change only the gecko compiler seemed to be related to more
stuff than I expected getting compiled with the gecko compiler, but
that's my confused impression of what was going on and doesn't really
matter here.)
As for bug 1239082, it started as bug 1236835 that originally planned to
turn off *all* buildbot based b2g desktop builds. When I stated that I
still needed the hazard builds, Callek reduced his changes so that he'd
turn off all but the hazard builds, then forked off bug 1239082 to
finish up the job after I migrated the hazard builds to taskcluster. I'm
working on that (that's the thing I said works locally on my laptop
now), but I did it as a mulet-based build so I wouldn't have to deal
with the b2g build system again, at least until we decided we needed the
ril coverage back.
Only now with b2g being tier-3, I'm thinking that if b2g needs that
coverage back, then a person who is not me can port my mulet build
changes over to the emulator build script, and I will congratulate
not-me on a job well done and breathe a sigh of relief that not-me is,
in fact, not me.
On 01/25/2016 01:06 PM, nhir...@mozilla.com wrote:
More over : https://bugzilla.mozilla.org/show_bug.cgi?id=1239082 ; Aren't we
disabling all Buildbot Based b2g desktop "hazard" builds on all trees ?
On Monday, January 25, 2016 at 12:26:58 PM UTC-8, nhi...@mozilla.com wrote:
I think the QC gonk layer had required 4.7 to lunch.
As far as I know you would have had to use the emulator from the get go if you
wanted to test the ril? The ril is in the Gonk layer as far as I know still
and the Gonk layer isn't in the mulet nor desktop builds...
On Monday, January 25, 2016 at 10:36:35 AM UTC-8, Steve Fink wrote:
On 01/25/2016 09:40 AM, Fabrice Desré wrote:
On 01/25/2016 09:30 AM, Ehsan Akhgari wrote:
For example, for a long time b2g partners held back our minimum
supported gcc. Now that there are no such partner requirements, perhaps
we can consider bumping up the minimum to gcc 4.8? (bug 1175546)
We moved to 4.8 on b2g a year ago: see
https://bugzilla.mozilla.org/show_bug.cgi?id=1056337
Who's behind? :P
I am.
The b2g rooting hazard analysis build is still using gcc 4.7. I spent a
bunch of effort trying to upgrade it to gcc 4.9, but ran into a variety
of issues I didn't understand related to the b2g build system (both on
my local laptop and on a build slave), and finally gave up in despair.
But the b2g hazard build is also a mozharness tangle of mixins and weird
inheritance structure (as is the older b2g emulator build), and those
are being replaced with taskcluster-based builds.
In the last 2 weeks, I've been working on redoing the b2g hazard build
on top of taskcluster and mulet. Partly because it's mulet, and partly
because it uses Docker and simple shell scripts, it has been *way* way
way way way *way* easier and more pleasant to deal with. I have it
working locally, so I hope to have the b2g hazard builds upgraded to gcc
4.9 soonish.
But that's on top of mulet, which means it isn't compiling any of the
MOZ_B2G_RIL code, which means it has lost some coverage over the
original build. If I understand correctly, the "right" thing to do would
be to use an emulator build instead, but that means that the b2g build
system gets involved again, which is complex and slings around a lot
more data, so everything is far slower to work on.
With FxOS becoming tier 3, I am disinclined to even attempt the emulator
version. In theory, it would be a straightforward adaptation of the
mulet hazard build script. In practice, it would take a while to even
test out that theory.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
