One further point of clarification: gyp depends != msvs dependencies For example if in gyp you have: progA --> libB --> libC
In msvs you will get: progA --> libB progA --> libC (unless as mark mentioned hard_dependency is used) -BradN So in terms of missed parallelism the current behavior should actually have you covered (though we have debated whether this behavior is confusing).Currently when library A depends on library B in the gyp sense, settings are shared, and when A is linked into an executable/shared library etc B will be linked in too, but the build shouldn't be serialized. For example On Mon, Sep 28, 2009 at 3:00 PM, Nick Carter <[email protected]> wrote: > On Mon, Sep 28, 2009 at 11:27 AM, Mark Mentovai <[email protected]> wrote: > > 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. > > > I agree 100% that the settings should be defined in one place and reused. > > > 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. >> > > You're right, the transitive form sounds awful in practice. Sorry for > suggesting it. > > 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." > > > I've been assuming that a 'dependencies' entry between two targets implies > the serialization of their build order, and a missed opportunity for build > parallelization. If so, then it seems common that an intermediate library > target would want to be able to pull in the settings from another target, > but not serialize the build. > > When writing build rules for sync, I experimented with a pattern where the > dependent settings were split into their own target, like: > 'target': { > 'name' : 'libfoo_includes', > 'direct_dependent_settings': { > 'defines': [ 'LIB_FOO_LEAN_AND_DELIGHTFUL' ], > 'include_dirs': [ 'third_party/libfoo2/files/' ], > } > # Nothing else here except the dependent settings. > } > > 'target': { > 'name': 'libfoo', > 'dependencies': [ > 'libfoo_includes', # allows reuse of settings inside this target. > ], > 'export_dependent_settings': [ > 'libfoo_includes', > ] > 'sources': [ > # . . . > ] > } > > This would allow downstream modules to have their choice of depending on > 'libfoo' or 'libfoo_includes'. This is where the mix-in suggestion came > from in my original email; it could potentially be nice to inherit settings > via libfoo_includes without having to create an empty project > libfoo_includes.vcproj. > > - nick > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
