S,o as it happens, I just had someone on nacl make the first use of multiple
inheritance this morning.
He hasn't checked it in yet, but the use case is:
'Common': {
# bunch of global stuff
'defines': [
# bunch of 32-bit defines.
],
},
'Debug': {
# bunch of general debug stuff assumes 32-bit
'inherit_from': ['Common'],
},
'Release': {
# bunch of general release stuff assumes 32-bit
'inherit_from': ['Common'],
},
'Common_x64': {
# Customizations to change 32-bit -> 64-bit
'abstract': 1,
'defines!': [
# bunch of 32-bit defines
],
'defines': [
# bunch of 64-bit defines
],
},
'Debug_x64': {
'inherit_from': ['Debug', 'Common_x64'],
},
'Release_x64': {
'inherit_from': ['Release', 'Common_x64'],
},
This use case seems reasonable enough.
It might fit into something like (b), but at least as currently conceived,
'Common_x64' has overrides of stuff in 'Common'.
It might be possible to refactor Common and Common_x64 to avoid collisions,
maybe pull out all the 32-bit stuff into Common_x86 and leave Common with
truly common stuff. On the other hand, the current arrangement allowed a
fairly small modification while 64-bit is being experimented with.
Suggestions?
-BradN
On Mon, Nov 2, 2009 at 3:12 PM, Mark Mentovai <[email protected]> wrote:
> We've got the "gypd" (d = debug) sorta-generator format as an option,
> alongside xcode, msvs, make, etc. It dumps the dicts it receives as
> .gypd files next to your .gyp files, so you can see what would be fed
> to a generator. You might need to feed it some -D because it's not
> tied to an OS by default.
>
> Albert J. Wong (王重傑) wrote:
> > On Sun, Nov 1, 2009 at 3:26 PM, Bradley Nelson <[email protected]>
> > 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 <[email protected]
> >
> >>> 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 <[email protected]>
> wrote:
> >>>>>
> >>>>> What does the syntax look like?
> >>>>> - nick
> >>>>>
> >>>>> On Thu, Oct 29, 2009 at 3:22 PM, Bradley Nelson <
> [email protected]>
> >>>>> 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: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
