On 29 December 2010 16:46, Esteban Lorenzano <
[hidden email]> wrote:
>
> 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.
okay. it is never late to refactor it later :)
> 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 :)
>
ouch.. no. lets keep it simple :)
> Cheers,
> Esteban
>
> El 29/12/2010, a las 12:38p.m., Igor Stasenko escribió:
>
>>
>> On 29 December 2010 16:27, Esteban Lorenzano <
[hidden email]> 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.
>
>
--
Best regards,
Igor Stasenko AKA sig.
Locked
