Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-Igor.Stasenko.7.mcz
==================== Summary ====================
Name: CMakeVMMaker-Igor.Stasenko.7 Author: Igor.Stasenko Time: 29 December 2010, 3:50:26 am UUID: 8c273498-1297-448a-be50-98826312ef9e Ancestors: CMakeVMMaker-Igor.Stasenko.6
- added support for building external plugins. - external plugins are _not_ bundled but placed as a .dylib in app bundle's Resources directory.
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
I vote for subclassing :)
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.
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.
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.
On 29 December 2010 16:46, Esteban Lorenzano estebanlm@gmail.com 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 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.
vm-dev@lists.squeakfoundation.org