[Vm-dev] Proposal to rename all CMakeVMMaker configuratiosn

[David Graham]

On Apr 22, 2011, at 7:36 PM, Igor Stasenko wrote:

> 
> On 23 April 2011 03:12, David Graham <dgraham at unthinkable.org> wrote:
>> 
>> Sorry if this is beyond the scope of the current topic, but having recently ran into issues trying to create a CMakeVMMake config for FreeBSD, I wanted to ask if anyone has considered moving from deep hierarchies to containers for platform targets?
>> 
>> As I mentioned in a previous email, half of the FreeBSD config methods exist only to remove flags and features added in the unix superclasses.  Even the base Unix class (CUnixConfig) has flags specific to Linux using ALSA and a recent Gnu toolchain.  The easy answer would be to move the flags further up into the hierarchy, but considering the overlap of code for platforms (esp. OSX and Unix) and the potential diversity of future platforms (Ubuntu with Wayland and no X11, OSX/BSDs compiled with clang, or even Google's NaCl) left me wondering if working towards a flatter and more flexible model would be worthwhile?
> 
> I am not sure i understood well your suggestion.
> Are you suggesting to not use inheritance model for configs?
> 

Hi Igor,

No, I like the inheritance model.  I was just wondering if doing things like moving compiler or plugin definitions out of platform class methods and into their own objects would give more flexibility and be a good long term investment.  A platform target could still have a hierarchy, but be defined as a container of objects instead of a class of method overrides.  When I need a config for a linux/arm tablet or headless x86_64 server, it's a matter of defining what objects to include instead of trying to figure out where to hook into an existing class hierarchy and what methods to override.

> The thing is that it depends on diversity. For instance making debug
> variant of existing config is easy job, because it requires to put few
> overrides in few methods.
> But of course when we talking about two different platforms, the
> number of common code in configs are much less.
> 
> I think the rule of thumb here is simple: produce _working_ configs
> first improve them later :)
> It is good when code reused, but i don't see a big disaster in
> duplicating the code in two different configs. Because , as you
> pointed out, they are subject to change anyways,
> once you refine settings to be more and more appropriate for specific
> platform or target.
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.