Ignore everything below the -BradN in my last message. (mmentovai beat me to the punch on replying :-) ) -BradN
On Mon, Sep 28, 2009 at 3:23 PM, Bradley Nelson <[email protected]>wrote: > 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 -~----------~----~----~----~------~----~------~--~---
