I don't understand how CMake uses VMMaker

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

I don't understand how CMake uses VMMaker

Mariano Martinez Peck
 
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 ?

2) Why you see all plugins as external to VMMaker ?  In #prepareVMMaker you do:

allPlugins := self internalPlugins , self externalPlugins.
   
  maker externalModules addAll:  allPlugins.


I think this deserves a comment because it sounds pretty weird from a newbie sight.

Thanks in advance,

--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: I don't understand how CMake uses VMMaker

Igor Stasenko

On 17 April 2011 00:16, Mariano Martinez Peck <[hidden email]> 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. :)


> 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.

>
> 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.

> Thanks in advance,
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: I don't understand how CMake uses VMMaker

Mariano Martinez Peck
 


On Sun, Apr 17, 2011 at 12:34 AM, Igor Stasenko <[hidden email]> wrote:

On 17 April 2011 00:16, Mariano Martinez Peck <[hidden email]> 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 ?


 
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: I don't understand how CMake uses VMMaker

Igor Stasenko

On 17 April 2011 00:42, Mariano Martinez Peck <[hidden email]> wrote:

>
>
>
> On Sun, Apr 17, 2011 at 12:34 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 17 April 2011 00:16, Mariano Martinez Peck <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:

On 17 April 2011 00:42, Mariano Martinez Peck <[hidden email]> wrote:
>
>
>
> On Sun, Apr 17, 2011 at 12:34 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 17 April 2011 00:16, Mariano Martinez Peck <[hidden email]> 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