tree 31d5a8e953b338c9fa6a68b1604d7125952fa125
parent ff14fc1112e0a8dd2c3910fb89539741cb3d3f23
author Adrian Taylor <adetaylor@chromium.org> 1648245957 -0700
committer Commit Bot <commit-bot@chromium.org> 1648247061 +0000

Make more variables available to scripts.

This change makes certain extra variables available to 'action' target types,
i.e. scripts. Those variables are:
* defines
* include_dirs
* rustenv
They are deduced from any configs applied to the target, so
configs also now applies to 'action' targets.

These variables are normally exclusively used by compilers, and no compiler-
specific variables have been made available to scripts previously. Here's
why they're needed.

rustenv:

This variable represents environment variables passed to the Rust
build, and in the Chromium tree this is assembled using various transitive
'config's. These environment variables are typically used to allow `env!`
directives within the Rust code to work properly; often (but not always)
this is to support pre-existing third party Rust code ("crates").

Such pre-existing third party Rust code also expects the same environment
variables to be present when the crates' build scripts are run. In a gn
environment, these build scripts are run using an 'action', and therefore
we need to make this rustenv value available to 'action' targets.

This is described in https://chromium/1304254.

defines/include_dirs:

In Rust development it is common to produce Rust bindings to pre-existing
C/C++ headers. This is not built into rustc, but is instead a facility
provided by separate codegen tools - the most commonly known example being
bindgen (https://rust-lang.github.io/rust-bindgen/). In a gn environment,
these tools are run as a gn 'action' target.

Such tools involve parsing C/C++ headers (using something like libclang).
In order to parse headers properly, such tools obviously need to be aware
of the full list of -I and -D flags active in the current environment.
In Chromium, such -I and -D flags are assembled using a graph of complex
transitive gn 'config's, and there's no realistic prospect of hard-coding
equivalent command lines.

'bindgen' therefore absolutely has to have access to the 'include_dirs'
and 'defines' set using gn configs. One solution here is to define a
whole new toolchain where we inform GN that bindgen is a compiler - this
solution is outlined in https://chromium/1296241 - however this is not
ideal. To parse (say) just base/cpu_info.h, we would need to depend upon
  //base(//toolchains/fake_bindgen_toolchain)
which will run a command to 'compile' every .cc file within //base.
This can be 10,000s of extra ninja rules, and even if most of them
are just a 'touch' command, this is still a great deal of extra complexity.

Bug: chromium/1272780, chromium/1296155, chromium/1296241, chromium/1304254
Change-Id: Ib60067b310d8508f61d04fe7ddc537a5d2c2917f
Reviewed-on: https://gn-review.googlesource.com/c/gn/+/13220
Reviewed-by: Brett Wilson <brettw@chromium.org>
Commit-Queue: Brett Wilson <brettw@chromium.org>