[Vm-dev] I don't understand how CMake uses VMMaker

[Mariano Martinez Peck]

Thanks. I commited:

Name: CMakeVMMaker-MarianoMartinezPeck.90
Author: MarianoMartinezPeck
Time: 19 April 2011, 1:22:12 pm
UUID: 196e7bb1-3afa-4a3c-a517-f2e327379999
Ancestors: CMakeVMMaker-MarianoMartinezPeck.89


Just added some comments to explain why we used 'Cross' for VMMaker, and why
all plugins were put as external

On Sun, Apr 17, 2011 at 12:48 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 17 April 2011 00:42, Mariano Martinez Peck <marianopeck at gmail.com>
> wrote:
> >
> >
> >
> > On Sun, Apr 17, 2011 at 12:34 AM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> >>
> >> On 17 April 2011 00:16, Mariano Martinez Peck <marianopeck at gmail.com>
> wrote:
> >> >
> >> > Hi Igor. I was debugging a little the CMake generation and there are 2
> things I don't understand:
> >> >
> >> > 1) Why you always use a "Cross" VMMaker instead of the specific OS ? I
> mean, in #prepareVMMaker you do:
> >> > maker := VMMaker forPlatform: 'Cross'.
> >> > Shouldn't you put the correct OS ?   what are the differences doing so
> ?   was the functionality of those special classes like Win32VMMaker,
> UnixVMMaker, etc.. moved the CMakeVMMaker confs ?
> >> >
> >>
> >> Thanks to Eliot, generated sources are not differ from one to another
> >> platform, therefore Cross is ok. :)
> >>
> >
> > Ok, I will add such comment to the code.
> >
> >>
> >> > 2) Why you see all plugins as external to VMMaker ?  In
> #prepareVMMaker you do:
> >> >
> >> > allPlugins := self internalPlugins , self externalPlugins.
> >> >
> >> >   maker externalModules addAll:  allPlugins.
> >> >
> >>
> >> This is to specify which plugins sources to generate.
> >> The sources output are not different whether plugin will be external
> >> or not, therefore i just adding them to single list.
> >>
> >
> > But since when it is not different?  Again, thanks to Eliot ?
> > I mean, there should be a reason why there were 2 instVar, one for
> internal and anotehr one for external. In fact, when I used VMMakerTool you
> need to define for each plugin how to compile it.
> > This is why I don't understand why you now say it is the same.
> > I do understand that the sources generation is the same, wether they are
> internal or external. BUT, why VMMaker needed to know whether they were
> internal or external then ? and why we don't need it anymore ?
> >
>
> AFAIK, they are used to generate plugins.int and plugins.ext files,
> but CMake controls this directly (by generating corresponding
> configuration(s)) so these files are nothing else but just leftovers
> and not used anymore.
>
> Also, since with CMakeVMMaker we can control various linking/compiling
> options per plugin basis, there is also no longer need to manually
> write MakeFile(s) per plugin.
>
>
> >> >
> >> > I think this deserves a comment because it sounds pretty weird from a
> newbie sight.
> >> >
> >>
> >> I think a CodeGenerator deserves a bit of cleanup to reflect the
> >> changes described above.
> >> And since Cog VMs are not using GUI for generating sources, things
> >> like VMMakerTool can rest in peace.
> >> Personally i found it much simpler  to control internal/external
> >> plugins using CMakeVMMaker classes,
> >> comparing to old ways, when you had to manually add all plugins using
> GUI tool.
> >> Especially, when some plugins are fit only for specific target (like
> >> ThreadedFFIPlugin),
> >> or only for specific OS, like MacMenuBarPlugin.
> >
> > Yes, exactly. +100. If you read my blog post, that's exactly my opinion.
> >
> >>
> >> > Thanks in advance,
> >> >
> >> > --
> >> > Mariano
> >> > http://marianopeck.wordpress.com
> >> >
> >>
> >> --
> >> Best regards,
> >> Igor Stasenko AKA sig.
> >
> >
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110419/09aaeaab/attachment.htm