Add options for host/target OS/arch.

Add options for host/target OS/arch.

Add options to gyp which store the host and target's OS/architecture, to
be used by generators and also exposed to gyp files as default
variables. They can be specified as command line options or in the
environment; the host is detected by default, and the target defaults to
the same as the host.

This does not yet replace the existing "flavor" variable in gyp
(exported as "OS" to gyp files); this will be done in a later CL as
there are a number of usages that need to be correctly sorted into
host-vs-target.

BUG=gyp:325

[Torne, 2013-03-11 16:16:50]

Hi Ryan, Sam, anyone else who is interested:

This is the interface I have in mind for making gyp aware of host and target
OS/arch. This patch doesn't actually replace the existing usage of flavor; I'll
do that in a followup if this is okay.

Does this look reasonable?

https://codereview.chromium.org/12638013/diff/1/pylib/gyp/__init__.py
File pylib/gyp/__init__.py (right):

https://codereview.chromium.org/12638013/diff/1/pylib/gyp/__init__.py#newcode73
pylib/gyp/__init__.py:73: default_variables['TARGET_OS'] = options.target_os
Currently there is a variable OS that's set by some (but not all) generators to
the flavor; for compatibility with existing gyp files we probably want to set OS
to options.target_os, but I won't do that until I've replaced all the existing
uses of flavor inside gyp.

https://codereview.chromium.org/12638013/diff/1/pylib/gyp/common.py
File pylib/gyp/common.py (right):

https://codereview.chromium.org/12638013/diff/1/pylib/gyp/common.py#newcode405
pylib/gyp/common.py:405: """Returns the system's architecture."""
This matches all the machine types that are currently matched by v8's
architecture detection embedded in its gyp file (and also the machine types
matched by the similar code in Chromium's src/build/android/envsetup.sh) - if
there are other machine types we should detect, they can be added here as well,
but this should be enough for Chromium.

[Ryan Sleevi, 2013-03-11 21:23:07]

I've removed myself from reviewers, you likely want Brad, as he was most
involved in the cross-compilation discussions, IIRC.

It took me a few minutes to remember the context of why you're exposing this in
GYP (poor short term memory - previous discussion at
https://groups.google.com/d/msg/gyp-developer/2E2xE3OvYkg/fbUWVTMKHpYJ ), rather
than making it something that individual GYP files use (eg: via variables).

The only reaction I'd have is whether or not it makes more sense to go Brad's
suggestion from https://codereview.chromium.org/12256017/#msg8 - which was,
rather than putting this in the "core" language, have GYP have a 'default'
include.gypi that setup variables that are meaningful for projects to work "out
of the box"

[Torne, 2013-04-18 15:21:39]

Abandoning this due to a lack of interest. The problems I was intending to solve
using this infrastructure I have addressed in other, more hacky (but working)
ways.

[bradn, 2013-06-28 18:34:46]

This actually seems like an incremental improvement.
I'm ok with this going in unless there are any objections from others?
It doesn't address all the weird cases like nacl, but it move common stuff to
one place.
I suppose the target could go in a common.gypi in tools/gyp that everyone would
reference, but it seems like going thru the plumbing in two places is less than
ideal.

LGTM

[bradn, 2013-06-28 18:37:01]

We might want to add more arches.
Also it might be worth putting this critical piece of logic in a separte python
file?

[Nico, 2013-07-05 21:50:50]

https://codereview.chromium.org/12638013/diff/1/pylib/gyp/__init__.py
File pylib/gyp/__init__.py (right):

https://codereview.chromium.org/12638013/diff/1/pylib/gyp/__init__.py#newcode75
pylib/gyp/__init__.py:75: default_variables['TARGET_ARCH'] = options.target_arch
On Mac (and iOS), targets can have multiple target archs (via ARCHS). I think
that's possible to model with the current #target / #host stuff, but won't be
possible with this.

[Torne, 2013-07-16 09:51:03]

On 2013/07/05 21:50:50, Nico wrote:
> https://codereview.chromium.org/12638013/diff/1/pylib/gyp/__init__.py
> File pylib/gyp/__init__.py (right):
> 
>
https://codereview.chromium.org/12638013/diff/1/pylib/gyp/__init__.py#newcode75
> pylib/gyp/__init__.py:75: default_variables['TARGET_ARCH'] =
options.target_arch
> On Mac (and iOS), targets can have multiple target archs (via ARCHS). I think
> that's possible to model with the current #target / #host stuff, but won't be
> possible with this.

I don't think this makes anything any worse, unless I'm missing something about
how mac works. The point of having these variables is in order to be able to
make conditional tests on them in gyp files. If you are trying to make a fat
binary, the current target/host split isn't sufficient to actually have any
conditions that are specific to which of the architectures you are building for;
all the flags/etc in your gyp file are going to be for the entire fat binary
target, no? gyp only instantiates one copy for host and one copy for target; the
generator's free to go ahead and build a fat binary if it wants, but the input
stages of gyp are not aware that there's any distinction between target-32-bit
and target-64-bit, or whatever.

If we want something that's going to deal with fat binaries, 32-bit plugins on
64-bit platforms, etc without it being a hack, then we're going to have to make
much larger changes to gyp than this (make the set of toolsets arbitrary? but
currently generators rely on being able to distinguish host vs target in order
to, say, generate different linker command lines).

If you have an idea for how we can do this more flexibly, then that'd be great.
All I want is for there to be a standard way in gyp to do conditional tests and
generator evaluation based on the host and target OS/arch as properly
differentiated entities, which right now there isn't (we just have "OS" which is
the target).

[Sam Clegg, 2015-02-27 21:41:41]

On 2013/07/16 09:51:03, Torne wrote:
> On 2013/07/05 21:50:50, Nico wrote:
> > https://codereview.chromium.org/12638013/diff/1/pylib/gyp/__init__.py
> > File pylib/gyp/__init__.py (right):
> > 
> >
>
https://codereview.chromium.org/12638013/diff/1/pylib/gyp/__init__.py#newcode75
> > pylib/gyp/__init__.py:75: default_variables['TARGET_ARCH'] =
> options.target_arch
> > On Mac (and iOS), targets can have multiple target archs (via ARCHS). I
think
> > that's possible to model with the current #target / #host stuff, but won't
be
> > possible with this.
> 
> I don't think this makes anything any worse, unless I'm missing something
about
> how mac works. The point of having these variables is in order to be able to
> make conditional tests on them in gyp files. If you are trying to make a fat
> binary, the current target/host split isn't sufficient to actually have any
> conditions that are specific to which of the architectures you are building
for;
> all the flags/etc in your gyp file are going to be for the entire fat binary
> target, no? gyp only instantiates one copy for host and one copy for target;
the
> generator's free to go ahead and build a fat binary if it wants, but the input
> stages of gyp are not aware that there's any distinction between target-32-bit
> and target-64-bit, or whatever.
> 
> If we want something that's going to deal with fat binaries, 32-bit plugins on
> 64-bit platforms, etc without it being a hack, then we're going to have to
make
> much larger changes to gyp than this (make the set of toolsets arbitrary? but
> currently generators rely on being able to distinguish host vs target in order
> to, say, generate different linker command lines).
> 
> If you have an idea for how we can do this more flexibly, then that'd be
great.
> All I want is for there to be a standard way in gyp to do conditional tests
and
> generator evaluation based on the host and target OS/arch as properly
> differentiated entities, which right now there isn't (we just have "OS" which
is
> the target).

Are you still interested in landing this change or can we close this issue?

[Torne, 2015-02-28 09:36:33]

On 2015/02/27 21:41:41, Sam Clegg wrote:
> Are you still interested in landing this change or can we close this issue?

No, with the migration to gn in progress I don't think it's particularly
valuable to put a lot of work into gyp supporting odd cases of toolchain
combinations when we already know that none of the toolchain support in gyp is
really flexible enough for chromium's needs.