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@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.