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