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
-~----------~----~----~----~------~----~------~--~---

Reply via email to