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