[Vm-dev] OSProcess fork issue with Debian built VM

K K Subbu kksubbu.ml at gmail.com
Fri Jun 2 16:54:29 UTC 2017


On Friday 02 June 2017 04:50 PM, Holger Freyther wrote:
>
>> +1. I would go further and propose that plugins, other than those
>> which are integral to VM[1], be moved into separate projects and
>> built in their own tree with no references to vm source paths. They
>> should be free to organize their platform-specific and
>> platform-independent code and makefiles.
>
> why? How many plugins are used that don't ship with the pharo-vm (or
> squeakvm)? I have to say I like the pharo-vm approach a lot where the
> VMMaker* packages and generated sources sit next to each other.

My proposal is to loosen build time coupling, not packaging. Nothing 
prevents plugins built out of tree from being built, installed and 
shipped together. Supporting out of tree plugins allows others to extend 
a VM even long after its release.

Eliot has already responded to your example in detail, so I will not 
dwell upon it further, except to point out that we need a command line 
tool to generate a .c file directly from the plugin's mcz file. Then we 
can create a Make rule to compile a .o and get rid of .c file. e.g.

  FooPlugin.o : FooPlugin.mcz
	squeak -headless vmmaker.image gencc.st FooPlugin.mcz
	cc -c ... FooPlugin.c
	rm -f FooPlugin.c

where st2c should generate the .c file for FooPlugin from its Slang code 
in its package or from a .st file. There is no need for .c file to be 
human readable or be subject to version control. That will be very messy.

Regards .. Subbu


More information about the Vm-dev mailing list