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 <[email protected]> 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 <[email protected]>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: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---