[Vm-dev] VM Maker: CMakeVMMaker-Igor.Stasenko.7.mcz

[Esteban Lorenzano]

yeah... even then, I prefer subclassing. I think most of the times the configurations will be not combinable, and I also think is better to rule the generality than the exception.
And maybe we can create a "composite configuration" CMakeCompositeConfig with all the configurations you want combined... then you have the best of the two words :)

Cheers,
Esteban

El 29/12/2010, a las 12:38p.m., Igor Stasenko escribió:

> 
> On 29 December 2010 16:27, Esteban Lorenzano <estebanlm at gmail.com> wrote:
>> I vote for subclassing :)
>> 
> 
> well, the problem is that
> you could use multiple options, like
> 
> +debug +console
> 
> or
> 
> +debug +windowed
> 
> 
> or
> 
> + release +console
> ...
> etc
> 
> which means that for every build variant(s) combinations you will need
> a separate class.
> 
> But the bright side of subclassing is, of course, that you don't need
> to put branches everywhere,
> like crazy. :)
> 
> 
>> El 29/12/2010, a las 11:58a.m., Igor Stasenko escribió:
>> 
>>> 
>>> what is left is to:
>>> - add support for build variants
>>> 
>>> 
>>> But there is a question:
>>> should i introduce variants using same configuration class, i.e.:
>>> 
>>> CMakeVMGenerator new generate: CogMacOSConfig release.
>>> CMakeVMGenerator new generate: CogMacOSConfig debug.
>>> 
>>> 
>>> or it is better to use subclasses:
>>> 
>>> CMakeVMGenerator new generate: CogMacOSConfigRelease.
>>> CMakeVMGenerator new generate: CogMacOSConfigDebug.
>>> 
>>> I'm not sure how to better organize it, because on windoze, one might
>>> want to build:
>>> 
>>> [debug] [trace] command-line
>>> or
>>> [debug] [trace] windowed
>>> 
>>> 
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>> 
>> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.