Evaluating the toolchain definition scope

[Sylvain Defresne]

Hello all,

While investigating an issue in Chromium, I found that when defining a toolchain, the scope passed to the toolchain is evaluated in the context of the previous toolchain. By that, I meant that any variables coming from the global scope are those from the previous toolchain, even if their definition depends on `toolchain_args` overridden by the toolchain.

I understand that this is probably because the scope is evaluated before the toolchain can be defined, but this can lead to surprises if the toolchain uses variables from the global scope whose value ends up modified when the `toolchain_args` are applied (such as `is_component_build` in Chromium).

I've reported this as issue 286 but I'm not sure what to do.

First is this documented and defined as the expected interaction between defining a toolchain and overriding globals via `toolchain_args`. I've looked at `gn help toolchain` and even after my investigation, I'm still unclear whether this is documented.

If this is not the expected behaviour, how can we fix this?

1. Should the toolchain only use the `toolchain_args`, create the new toolchain context using the new overrides, and then evalue again the toolchain definition in that context?
2. Should the toolchain complain if its definition uses variables from the global scope that depends on any value overridden in `toolchain_args`? Or any variable from global scope?
3. Any other suggestions?

Regards,

-- Sylvain

[Nico Weber]

I think this is expected, see e.g. https://groups.google.com/a/chromium.org/g/gn-dev/c/F_lv5T-tNDM

[Roland McGrath]

This is indeed WAI.  It's IMHO a major wart but it's a real can of worms and there is no simple fix.  Fundamentally, toolchain setup can never be evaluated in the toolchain's own evaluation context, because it's responsible for configuration that evaluation context before its buildconfig is even evaluated.  There are other aggravations that come from this model, such as that `toolchain_args` are ignored for the toolchain definition that's set as the default toolchain.  I don't think there's any satisfactory solution that doesn't fundamentally redefine GN's semantics for how toolchains are defined.