I'd be willing to consider alternatives. The key thing here is that we need
a way to generate multiple configurations within a single expansion,
currently at least.
I suppose an alternative would be to have gyp expand things multiple times
with CONF or somesuch being each value from a list of config names. Then we
could use conditions gated the value of CONF.
This would have the drawback that we'd might have to expand large chunks of
the gyp files multiple times. But it might be more homogenous. Definitely
more major surgery.
For the example from before it would look something like:
'configurations': ['Debug', 'Debug_x64', 'Release', 'Release_x64'],
'configurations_settings': {
# bunch of global settings.
'conditions': [
['x64 in CONF', {
'defines': [
# bunch of 64-bit defines.
],
}, {
'defines': [
# bunch of 32-bit defines.
],
}],
],
['Debug' in CONF', {
# debug specific settings
}, {
# release specific settings
}],
},
I admit this syntax is slightly nicer, but I'm a little scared of the work
to get there.
Also, you'd still have the weird merging behavior for targets which alter
this per config. Though I guess that could also get changed:
'configurations': {
'Debug': {
'defines': ['extra_for_my_target_on_debug'],
},
},
==>
'configuration_settings': [
'conditionals': {
["Debug" in CONF': {
'defines': ['extra_for_my_target_on_debug'],
}],
],
},
I suppose the other route would be to refrain from configs altogether. This
is for instance how the linux folks have added 64-bit. They generate
different scons/make files at gyp time. Configurations are more limited, but
the IDE folks like being able to switch from a drop down.
-BradN
On Tue, Nov 3, 2009 at 1:33 PM, Albert J. Wong (王重傑) <ajw...@chromium.org>wrote:
> On Mon, Nov 2, 2009 at 3:37 PM, Bradley Nelson <bradnel...@google.com>wrote:
>
>> 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?
>>
>
> Sorry for the slow response to this...missed it in my inbox. :(
>
> It's hard to see w/o a concrete example, but in general I would have wanted
> to do it via conditionals inside 'Common.'
>
> Why rely on shadowing when you can explicitly do it via conditionals here?
>
> IMO, the more dimensions in which we have to alter how the final dictionary
> is created, the harder it will be to maintain -- especially if there
> construct is one which relies on order of lookup, and doesn't encourage
> co-locating where the decision is made for which modifications are included
> (with conditionals, you know the "else" portion is likely in the same file.
> With inheritance, it's all over the place.)
>
> -Albert
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
