Okay, after having stared at this for a while, it is somewhere between difficult and impossible to do this "correctly" in GN in a way that doesn't require packagers to define their own toolchains. 

The reasons are as follows:

To build chrome from scratch on linux for a single target architecture, you need to build some N different NaCl toolchains (which almost certainly should never have their flags overridden), plus four non-NaCl toolchains:

1) the main target toolchain
2) the main host toolchain
3) the "v8 snapshot" toolchain, which runs on the host but must generate code that matches the bit-width of the target
4) the "nacl bootstrap" toolchain, which basically requires its own highly customized set of flags and builds one target.

The first three toolchains can be explicitly selected via the `custom_toolchain`, `host_toolchain`, and `v8_snapshot_toolchain` build args. The fourth toolchain cannot be explicitly selected at the moment, but that's probably a bug; today it is configured based on the target_cpu setting and whether we're doing a CrOS target build.

In each environment, it's likely that a packager needs to override some or all of the following:

* which binaries to use for cc, c++, ld, ar, and readelf
* extra flags to set for CPP, C, CXX, and LD
* whether the toolchain is using (chromium's version of) Clang, since the build files may do clang-specific checks.

As a result, we end up with up to 35 custom build args that might need to be set.

In the current code, we do roughly this for ChromeOS, and the extra flags are appended at the end of any given command line. This is arguably not ideal, because it means that a given target cannot override the flags. 

In GYP, on the other hand, the extra flags were placed on the command line *before* the target-specific flags. We could change the current GN implementation to match this.

In addition, the current implementation is very-much un-GN-like, because the args are inlined straight into the command (i.e., taken as uninterpreted strings). A more GN-like way of specifying things would be to actually set the build args to lists of strings, and have them set via a config. For example, you might set `extra_cflags = [ '-Wfoo', '-Wbar' ]` rather than `extra_cflags="-Wfoo -Wbar". I took that approach in https://codereview.chromium.org/2202873002/ , but abandoned it after realizing that that would require us to change the CrOS ebuild to specify lists of strings instead of strings. In addition, that CL would've otherwise worked for CrOS, but it relied on knowledge of the way CrOS sets custom toolchains.

For a non-CrOS Linux packager, that CL wouldn't have worked even if the build args were set to lists, because when GN evaluated the "extra_flags" config, it would've needed to know which *type* of toolchain it was currently using (target/host/snapshot/bootstrap), and that information isn't currently available.

So, it's not clear what the best way forward is. The design of GN basically assumed that if someone wanted to do their own custom build of chromium, they would be willing to take the effort to define their own custom toolchain (like the CrOS team kinda did). If we can't expect a packager to do that, it's unclear what we can implement that will actually be correct. We can't easily provide just the functionality that GYP did, because in particular the way the v8 snapshot is built is fundamentally different (it figures out which flags to use based on the configured toolchain, rather than setting flags directly via a giant pile of hard-to-maintain conditions) (and, of course, the way NaCl is built is fundamentally different as well).

It's possible we can implement a limited set of knobs for some circumstances, e.g., give packagers a way to do a build for a single architecture (no cross-compiling, snapshot, target, and host all using the same toolchain) with no NaCl, for example.

However, I don't really know what will be acceptable.

So, since you're the one that has been pushing for this feature, phajdan.jr@, I'm going to bounce this to you to see what you think. Please read through all of this and let me know if/when you have questions, and we can figure out where to go next.

Removing myself from bugs because of team transfer, back to re-triage.

See https://goto.google.com/phajdan-goodbye-chrome (Google-internal) and  issue 783662  .

In case of any questions, feel free to ask - use phajdan@google.com for a faster response.