direct_dependent_setting is not transitive by design. This was intended to discourage targets from inheriting an ever growing list of header from their dependencies.
In the case were a module does not fully encapsulate its dependencies, there aretwo syntaxes that are currently supported that can help: 1. 'export_dependent_settings': [ list of gyp targets like base/base.gyp:base ] This allows a target to indicate that if you depend on it, then you also effectively depend on the listed targets too. So if module X uses module Y, and people using module X also need to include headers from Y, then this is the appropriate syntax to use. 2. 'all_dependent_settings': { settings block } This works just like direct_dependent_settings, but effects everything that dependents directly or indirectly on a target. YOU PROBABLY DONT WANT TO USE THIS. As it is rarely a good idea to have a module effect all downstream dependencies so broadly. The only case where this might make sense, is some sort of compiler flag which has to be on everywhere in relation to a target. -BradN On Mon, Sep 28, 2009 at 11:00 AM, Nick Carter <n...@chromium.org> wrote: > I've noticed that the use of the 'direct_dependent_settings' in gyp to > propagate #defines and include paths makes it trickier to decipher the > actual build-order dependencies. I've had cases where I needed to add a gyp > dependency just to get an #include path for a header file that was > transitively included by a bona-fide dependent. The pollution obscures the > actual dependency structure. > A transitive version of 'direct_dependent_settings' that works on indirect > dependencies might improve the situation. Another possibility is a > lightweight 'mix-in' target type that has no .vcproj associated with it, but > that can still impart the side effect of 'direct_dependent_settings' on its > dependents. > > - nick > > > On Sun, Sep 27, 2009 at 6:13 PM, Peter Kasting <pkast...@google.com>wrote: > >> Thanks Mark-Antoine. >> It has been a very long time since I fixed the dependencies years ago to >> not be so crazy. Not surprising that it is once again goofed up. >> >> It would be nice to have some of this stuff auto-calculated by GYP if that >> is feasible... >> >> PK >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---