[Vm-dev] [CMake] Can we create StackInterpreterDebugMacOSConfig ?

[Igor Stasenko]

On 1 April 2011 14:55, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
> I don't have commit access to VMMaker, so I attach de mcz
>
> Name: CMakeVMMaker-MarianoMartinezPeck.57
> Author: MarianoMartinezPeck
> Time: 1 April 2011, 2:53:25 pm
> UUID: 4fc51c2f-d626-439d-869d-b1bd60c23a89
> Ancestors: CMakeVMMaker-MarianoMartinezPeck.56
>
> New classes CogDebugMacOSConfig and StackInterpreterDebugMacOSConfig
> that implements #compilerFlags
> so that to answer the debug ones.
>
>
>
> Anyway...I don't like a new class just for implementing #compilerFlags  ^
> self compilerFlagsDebug.
>
> I would prefer use the same class and do: CogMacOSConfig
> generateForDebugWithSources
>

There is a zillions of various options which you can play with and get
VM built with it.
The problem is, that then you will have all those
generateWithFooButWithoutBar

and it will get messy quite fast.

I wanted  to do like that originally, but were driven in right
direction by Esteban, who proposed to use separate class(es)
for each concrete configuration we well be using. Because in this way
it defines a configuration which works out of the box,
and you don't need additional knowledge (what options you can set, or
what special selectors to run it etc etc).
Classes are cheap. And this package is service package anyways, so who
cares if there will be hundreds of configs :)

After all, people are free to create own modifications of
configuration(s) through subclassing.

And it proves to be quite simple, because when you starting from
already working configuration,
and just modify some bits here and there, and quite easily you got
another working configuration.

But if you explode config with various options, then subclasses have
to support them too..
but the problem is that they could come into conflict with each other,
and moreover, people will be obliged
to discover & test building them all.


> Cheers
>
> Mariano
>

-- 
Best regards,
Igor Stasenko AKA sig.