GitLab

NaCl and V8 have more complicated requirements for handling architectures
than GN could previously handle. This CL reworks things to meet their
needs.

NaCl occasionally has the need to be able to override build_cpu_arch. This
comes up when they want to use a 32-bit host toolchain (i.e., build
32-bit "host" objects) on a 64-bit kernel. In addition, it is conceivable
that other projects will need this functionality on systems capable of
building for running programs for multiple architectures (any system
that can run both 32-bit and 64-bit binaries), and there is no way that
GN can always correctly guess which arch to use by default.

V8 has the need to be able to run a host toolchain that knows what the
requested target cpu_arch is; we can not use the existing "cpu_arch" for
this because that needs to be the cpu_arch of the current toolchain.
The concrete example is running a host binary on Linux x86 that needs to
get specific flags to target arm (rather than x86), for example. We could
solve this in the build configs by passing custom variables across the
toolchain, but this suggests that we should have a general solution to
track these things, which is what this CL does.

This CL introduces two new predefined variables -- target_cpu and
target_os -- and renames cpu_arch and os to to 'current_cpu' and
'current_os', and renames build_cpu_arch and build_os to
host_cpu and host_os for consistency.

current_cpu and target_cpu default to the same value as
host_cpu, and current_os and target_os default to the same value
as host_os.

Any of these variables is (and should be) overridable on the command line
or in a build config file. We want them to be overridable because (a) it's conceivable
that some projects might always want fixed values for target_os and
target_cpu_arch regardless of what platform GN is running on, and (b) we might
want to set the values based on other values (i.e., have target_cpu_arch
default to "arm" if target_os == "android").

Due to the renaming of "os" and "cpu_arch", this CL is likely to break any and
all existing project builds; projects will need to update their build configs when
rolling in the new binary.

R=brettw@chromium.org
BUG=344767

Review URL: https://codereview.chromium.org/914873002

Cr-Commit-Position: refs/heads/master@{#317120}