Nick Carter wrote:
> The pollution obscures the actual dependency structure.
One man's pollution is another's...?
Seriously, we do this because the typical pattern is to say "anyone
that depends on this library needs to use these include directories or
have these macros defined." With 120 or so "targets," maintaining
these settings on the consumers (dependents) instead of the
dependencies is a huge loser. These are settings that belong on the
dependency target. The GYP model was designed to track the use of
using_*.vsprops files that we used to use in the MSVS-based build.
> A transitive version of 'direct_dependent_settings' that works on indirect
> dependencies might improve the situation.
We do have a way to do that, but it's actually almost never what anyone wants.
In the early days of GYP, I spent a lot of time barking at people who
tried to abuse the transitive form. In almost all cases, what you
really want actually is direct_dependent_settings or link_settings, or
in special cases, direct_dependent_settings +
export_dependent_settings. Brad covered these in detail in his
response 7 minutes ago, so I'm not going to repeat what he said. He
also used some CAPITAL LETTERS in his post, so I don't need to bark
this time either.
Mark
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
