gn isn't backwards compatible

[richardlau]

Since depot_tools used by V8 doesn't host binaries for non-Intel platforms we've had to build it from source on Linux PPC/s390x. #2675 added automation to our Ansible playbook to compile the latest commit of gn but gn itself is not versioned and apparently not backwards compatible with itself as can be seen from this recent V8 CI on a Node.js 14 PR:
https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=rhel7-s390x,v8test=v8test/4091/console

07:45:31 + gn gen -v out.gn/s390x.release '--args=is_component_build=false is_debug=false use_goma=false goma_dir="None" use_custom_libcxx=false v8_target_cpu="s390x" target_cpu="s390x" v8_enable_backtrace=true'
07:45:31 Using source root /data/iojs/build/workspace/node-test-commit-v8-linux/deps/v8
07:45:31 Got dotfile /data/iojs/build/workspace/node-test-commit-v8-linux/deps/v8/.gn
07:45:31 Loading //build/dotfile_settings.gni (referenced from //.gn:5)
07:45:31 Using build dir //out.gn/s390x.release/
07:45:31 Loading //build/config/BUILDCONFIG.gn
07:45:31 ERROR at //build/config/BUILDCONFIG.gn:401:1: Unknown function.
07:45:31 set_sources_assignment_filter(sources_assignment_filter)
07:45:31 ^----------------------------
07:45:31 make: *** [Makefile:276: v8] Error 1

The set_sources_assignment_filter "feature" was removed from gn.
Refs: https://groups.google.com/a/chromium.org/g/chromium-dev/c/hyLuCU6g2V4
Refs: https://groups.google.com/a/chromium.org/g/gn-dev/c/oQcYStl_WkI
Refs: https://bugs.chromium.org/p/gn/issues/detail?id=125

I'm going to roll back gn on the Linux PPC/s390x machines so we can run V8 CI for Node.js 12/14 for tomorrow's security releases.

We'll need to work out what to do about gn -- maybe either stash several versions and use a selector script or build gn from source for every V8 CI run based on the commit sha recorded in gn_version in deps/V8/DEPS. For release lines the version of gn used by V8 should be relatively stable but we also build V8 canary where I imagine gn would be updated more often.

[richardlau]

gn commits that removed the set_sources_assignment_filter feature in question:

• https://gn.googlesource.com/gn/+/ad0a7ada45cd7a3781a00175286a05519b4bdefc
• https://gn.googlesource.com/gn/+/55e535a6716e57320fdd3901f0347a5c30562199

We could try going to a version of gn immediately before those but then there's no guarantee it will continue to build V8 LKGR (as evidenced that we eventually needed to use a newer gn than the one we were using before for V8 9.2). I'm leaning slightly towards building the matching SHA as in V8's DEPS file with the open question as to whether we always build in every V8 CI run or adopt some sort of caching stategy.

[richardlau]

I suppose we could also look to see if we could patch up the V8 .gn build files but I feel that's too risky for the LTS releases.

[targos]

V8 removed uses of set_sources_assignment_filter in https://chromium-review.googlesource.com/c/v8/v8/+/2456988 and https://chromium-review.googlesource.com/c/v8/v8/+/2454079
They seem safe to backport to LTS.

[targos]

I opened nodejs/node#39244 and nodejs/node#39245

[richardlau]

Thanks. I’ll need to swap the symlinks for gn back to the more recent one.

[mhdawson]

I'm leaning slightly towards building the matching SHA as in V8's DEPS file with the open question as to whether we always build in every V8 CI run

If we built every time using ccache would that be pretty quick assuming it does not change very often?

[targos]

I opened nodejs/node#39244 and nodejs/node#39245

Both landed on the staging branches. This should fix the issue, at least temporarily.

[richardlau]

I'm going to close this for now as thanks to the great work done by @targos (🚀) in identifying changes to backport we have Node.js 12 and 14 able to build with more up-to-date versions of gn (i.e. we use the same gn binary on all releases). We can revisit if we run into the problem again in the future.