>
> 1) Do you support multiple inheritance? I notice the "inherit_from" is
> specified as an array. That's scaryish.
>
Multiple inheritance is supported, not sure it's wise to use, but well gyp
has lots of features like that :-)
I almost didn't support it, but concluded that, for instance 64-bit, might
have a common set of configuration properties that you'd want to mix-in to a
given config.
> 2) If you do have multiple inheritance, how are conflicts handled? Are
> they just rejected, or is there a pre-defined name resolution order? What
> would you do with diamond shapes?
>
Names are resolved based on the order in which parent classes are listed
after 'inherit_from'. Parent classes are applied depth first, and only the
first instance of a parent gets applied. So for example:
Base
/\ \
A B C
\ / /
D
Names are picked in this order: D, C, B, A, Base.
I'm not wedded to this arrangement (in fact I'm generally skeptical of
multiple inheritance).
I definitely think that in practice diamond inheritance should be avoided,
but I can imagine some cases were it might make sense.
I think in general we should try to have a single primary tree and mix-ins
for simple self contained features.
> 3) Is there a way to reference "super", or various ancestors?
>
No.
This gets implemented as merging (similar to target_defaults), so nothing is
left of the ancestors from the point of view of their descendants.
> 4) How does this interact with late-resolution variables?
>
Late resolution variables are expanded after inheritance.
There are serious limitations on what can happen in a configuration,
however, so I'm hard pressed to imagine a case where you'd be able to use
late-resolution in the context of a configuration.
> 5) How about conditionals? Can we conditionally inherit?
>
Conditionals are expanded before inheritance is applied, so you could in
principle make it conditional.
This is already being used in a related context (the Purify configuration
only exists for windows).
It might make sense with inheritance, but probably would be a bad idea.
It's supported largely as a side effect of normal gyp expansion.
If you feel strongly, we could take it out. I'm on the fence as to whether
its dangerous in the unusual context in which it applies to gyp.
Let me know. :-)
-BradN
> -Albert
>
>
> On Thu, Oct 29, 2009 at 5:42 PM, Bradley Nelson <bradnel...@google.com>wrote:
>
>> configurations can now inherit from one or more other configurations, and
>> configurations which are not fully expressed should be marked 'abstract': 1,
>>
>> So something like this:
>>
>> 'configurations': {
>> 'Common: {
>> 'abstract': 1,
>> # common settings
>> },
>> 'Debug': {
>> 'inherit_from': ['Common'],
>> # Debug specific
>> },
>> 'Release': {
>> 'inherit_from': ['Common'],
>> # Release specific
>> },
>> },
>>
>> -BradN
>>
>> On Thu, Oct 29, 2009 at 5:37 PM, Nick Carter <n...@chromium.org> wrote:
>>
>>> What does the syntax look like?
>>>
>>> - nick
>>>
>>> On Thu, Oct 29, 2009 at 3:22 PM, Bradley Nelson
>>> <bradnel...@google.com>wrote:
>>>
>>>> Hi All,
>>>>
>>>> I've just rolled out an enhancement to gyp to support inheritance in
>>>> configurations.
>>>> This shouldn't have any noticeable effect other than reducing the
>>>> repetition needed for things like Purify/notcmalloc.
>>>>
>>>> I've tested it as best I can, but please let me know if you experience
>>>> anything strange with Debug vs Release or with Purify/notcmalloc.
>>>>
>>>> This was primarily meant as a baby step towards supporting x64
>>>> configurations in gyp on windows, but I thought I'd let this part soak
>>>> first.
>>>>
>>>> -BradN
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
