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

Igor Stasenko siguctua at gmail.com
Sat Apr 16 22:48:15 UTC 2011


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.


More information about the Vm-dev mailing list