Since we're doing a different approach, let's split off this new bug for it. We can have Google's up-and-coming build system dump its dependency graph with `gn desc out '*'`, which we can process and translate into our own build system.

It works and builds for me locally. I revived github.com/mozilla/angle to hold our cherry-picked patches. Initial try run is here, though I expect it to basically explode: https://treeherder.mozilla.org/#/jobs?repo=try&revision=419862e84251b946dc33cea781f10eeb5759d8ff

Here's the full gecko branch, with nuke+update of ANGLE: https://github.com/jdashg/gecko-cinn/commits/angle-60 Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=95353dfac9dd0f4b630c835a3b343dc265562505&selectedJob=165135229 I'm still burning down MinGW and Linux Bb failures due to their older compilers. (current ANGLE assumes c++14, and we don't have full c++14 support, particularly around relaxed-constexpr) Here's the ANGLE branch that we're importing from: https://github.com/jdashg/angleproject/commits/firefox-60 This will end up in github.com/mozilla/angle, but I'm still overwriting history as I fix issues for now. The plan is that we use the mozilla/angle repo as a record of what we've imported into gecko. This also eases upstreaming and rebasing on top of newer versions of ANGLE. `git log gfx/angle` in Gecko should ideally show only changes to our gecko-only files (including the import script), as well as anything we have taken ad hoc since the last ANGLE update-from-mozilla/angle. The import script writes out a log (cherries.log) of the csets we have in mozilla/angle vs google/angleproject, as extra assurance that we know what we're pulling in. We want to get this reviewed ASAP, and fortunately there's not much to review closely. I need normal review for "Gecko changes due to ANGLE update", but I don't need close code review of the import script right now. (feedback welcome though) The script has a number of hacks to get it standing up, but it does a one-click import once set up.

Well, we're sort of entering soft code freeze, so we might prefer to slip this to 61. WebGL is fine (though disappointed) waiting until 61. Not sure what Web Render's needs are. Milan?

Hi, I just want to inform you that I (and maybe others I don't know) am waiting for this patch to land to be able to use WebRender daily on Fx Nightly (I am currently blocked by the black boxes issue #1422298). I don't know what can be the delay if you wait until 61 to land this, but for sure you will delay some bug reports from enthusiasts ;) Anyway, thanks for your hard work ! B.

(In reply to Jeff Gilbert [:jgilbert] from comment #6) > Well, we're sort of entering soft code freeze, so we might prefer to slip > this to 61. WebGL is fine (though disappointed) waiting until 61. Not sure > what Web Render's needs are. Milan? Let's keep trying for 60, and decide next week. Independent of WebRender.

Et voila: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c3b0a9897b0dea89f97ec5768a61d1c73237c8e4 I'll get an all-tests run rolling. jrmuizel: Please reassign review to kvark if you won't be able to review on Friday.

Comment on attachment 8955055 [details] Bug 1440849 - Add update-angle.py to facilitate updating Angle. - https://reviewboard.mozilla.org/r/224234/#review230692 Is it possible to just checkout into the 'angle' directory instead of a separate 'checkout' directory? That will keep the path names a little neater at the cost of mixing the gecko and angle files together.

Comment on attachment 8955055 [details] Bug 1440849 - Add update-angle.py to facilitate updating Angle. - https://reviewboard.mozilla.org/r/224234/#review230692 Of course, but I don't want them mixing, since that makes updating trickier.

Maybe, I we can come up with a better name than checkout. Overall though, I've done a quick read through of the patch and it seems mostly fine. This doesn't seem like it was the most fun to write :)

It should be simple enough to pick something different. FWIW, we did use "checkout" for the webgl conformance tests too.

Try-all looking pretty good: https://treeherder.mozilla.org/#/jobs?repo=try&revision=defe4f652ce819a41550ebc74015204f85eadc62

I talked some people about the 'checkout' name some people liked it some didn't. No one had a better suggestion so let's just leave it as is.

Comment on attachment 8955056 [details] Bug 1440849 - Gecko changes due to Angle update. - https://reviewboard.mozilla.org/r/224236/#review230764

Comment on attachment 8955055 [details] Bug 1440849 - Add update-angle.py to facilitate updating Angle. - https://reviewboard.mozilla.org/r/224234/#review230766

Pushed by jgilbert@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/f63d5bd89d78 Add update-angle.py to facilitate updating Angle. - r=jrmuizel https://hg.mozilla.org/integration/mozilla-inbound/rev/2479e330c5ea Gecko changes due to Angle update. - r=jrmuizel https://hg.mozilla.org/integration/mozilla-inbound/rev/cc6b8628c3bd Nuke old ANGLE. https://hg.mozilla.org/integration/mozilla-inbound/rev/97a40c8a4ce8 Mark Tests. https://hg.mozilla.org/integration/mozilla-inbound/rev/8ee92682ad1f Update ANGLE to firefox-60 branch.

(In reply to Jeff Gilbert [:jgilbert] from comment #0) > We can have Google's up-and-coming build system dump its dependency graph > with `gn desc out '*'`, which we can process and translate into our own > build system. Does it mean that Angle will also (and when?) switch to gn being necessary to bootstrap the build/generate moz.build files like it was done for webrtc in bug #1393119 ? That totally busted webrtc for non-tier1 platforms, cf bug #1437670 - so if that's the plan, please think of non-tier1.

My understanding of these patches is that gn is not used when building Gecko. It is only used when running the update-angle.py script, whose output (including moz.build files) is in the tree.

(In reply to Simon Sapin (:SimonSapin) from comment #22) > My understanding of these patches is that gn is not used when building > Gecko. It is only used when running the update-angle.py script, whose output > (including moz.build files) is in the tree. As long as the generated moz.build files somewhat provide a 'fallback' build config for non-tier1 platforms (ie most of the times, that means considering bsd is like linux), this would be fine. Bug #1442791 proved this wasnt the case...

https://hg.mozilla.org/mozilla-central/rev/f63d5bd89d78 https://hg.mozilla.org/mozilla-central/rev/2479e330c5ea https://hg.mozilla.org/mozilla-central/rev/cc6b8628c3bd https://hg.mozilla.org/mozilla-central/rev/97a40c8a4ce8 https://hg.mozilla.org/mozilla-central/rev/8ee92682ad1f