On Sun, Nov 1, 2009 at 3:26 PM, Bradley Nelson <bradnel...@google.com>wrote:
> 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.
>
So, I'm tempted to go two routes...none great.
a) disallow multiple inheritance initially. Until someone demonstrates a
need, don't add it.
b) validate the full inheritance tree to ensure there are no name
collisions. I think this becomes less trivial because of the conditional
inherit below. Though, I guess this static checking phase could also reject
conditional inherits (which I'm a bit of a fan of).
(a) Feels like the best initial route IMO. Going (b) sounds nice in theory,
but in other systems that I've used which reject collisions, it makes
configuration maintenance pretty annoying.
In the end, what I think would really help is actually a config differ.
Basically, so I can do
gyp printtree all.gyp
gyp printtree all.gyp_with_changes
and then diff the output, after various bits. Don't know if something like
this already exists.
-Albert
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
-~----------~----~----~----~------~----~------~--~---
