gyp doesn't handle <(DEPTH) in includes

[GoogleCodeExporter]

Currently, because we would like variable expansion to happen after includes 
have been applied, gyp doesn't handle <(DEPTH) being in an include correctly. 
This would be useful to support. We should either special case it, or even 
better implement lazy expansion + include, which would allow for greater 
flexibility.

Original issue reported on code.google.com by bradnel...@google.com on 2 Nov 2009 at 4:52

[GoogleCodeExporter]

The major reason that this doesn't work now is that variables may change as a 
result 
of including something.  Assume this.gyp:

'variables': {'branding%': 'chrome'},
'includes': ['build/<(branding).gypi'],
'conditions': [['branding=="chrome", {...1...}, {...2...}]],

and this build/chrome.gypi:

'variables': {'branding': 'notchrome'},

means that in this.gyp, sometimes "branding" has value "chrome" and other times 
"notchrome".

This can maybe become confusing, although if there are other changes made to 
bind 
late, then this sort of thing might happen in enough other areas that it 
wouldn't seem 
anomalous to do for includes.

Don't really know.  Just giving a little more context.

Original comment by mark@chromium.org on 2 Nov 2009 at 3:00

[GoogleCodeExporter]

There would definitely be some semantic issues to resolve in the context of 
late binding 
+ includes, not sure they really can be completely reconciled. Special casing 
expansion 
of <(DEPTH) in includes might be a more intuitive way to have our cake and eat 
it too, 
as people really shouldn't be redefining the depth.

Original comment by bradnel...@google.com on 2 Nov 2009 at 5:50

[GoogleCodeExporter]

I took a look at how input.py works and it looks like the early variable 
expansion is done too late, after the included dicts have been merged and one 
cannot tell whether a specific <(DEPTH) has come from a .gypi or from the .gyp 
(please correct me if I'm wrong).
How about having a special variable expansion phase used when the include files 
are being read? We could either let the users apply it to any variable by 
having a special prefix (e.g. "I(DEPTH)"), or reuse the "<" prefix, but expand 
only a small subset of variables at PHASE_INCLUDE (because it may be wrong to 
expand DEPTH, we can introduce INCLUDE_DEPTH for the depth of the include file).

Original comment by gli...@chromium.org on 24 Jan 2013 at 1:57

[GoogleCodeExporter]

I am hitting this issue in this CL: 
https://webrtc-codereview.appspot.com/35849004/

The main issue is that this this file is shared between webrtc and chromium, 
which have it at a different path depth. I am not sure what a good workaround 
would be? There is a variable that allows one to differentiate between a webrtc 
and a chromium checkout, I suppose I could set another variable to extend to 
the relative path.

Original comment by fdeg...@chromium.org on 22 Jan 2015 at 5:47

[GoogleCodeExporter]

After further testing, it looks like GYP cannot extend variable at all in an 
'includes' list.
Short of doing some unholy heavy copying, I am not sure what to do.

Original comment by fdeg...@chromium.org on 22 Jan 2015 at 5:58