Bradley Nelson wrote:
> If we move the gypi's to subdirectories, paths in them will still be
> relative to src/chrome, which might be confusing.
> I would prefer if gypi's didn't have this behavior, and plan to fix it:
> http://code.google.com/p/gyp/issues/detail?id=116

That bug only refers to the 'includes' section of a .gypi file in a
different directory than its including .gyp file.  I don't think
that's relevant here.

Path reparenting means that paths in a .gypi file should be treated as
relative to that .gypi file, not the including .gyp.  (With the
exception of paths in 'includes', apparently, which is GYP bug 116.)
Anything that's in input.py's path_sections or any value associated
with a *_dir, *_file, or *_path key or their plural forms, should
currently be subject to reparenting.  We currently rely on this
behavior in build/common.gypi.  As an example, at one point in that
file, I set a variable named 'strip_from_xcode_path' to
'mac/strip_from_xcode' and then use that variable in an action.  Only
build/mac/strip_from_xcode exists in our repository, but the path is
adjusted properly for each .gyp file that common.gypi is included
into.

'sources' is in path_sections, but you'll need to take care with
regular expressions for 'sources/': those aren't (and can't be) path
sections, and you might need to adjust the patterns to take this into
account.

Path reparenting has nothing to do with Julie.

Mark

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev

Reply via email to