Posted by
K K Subbu on
Jun 02, 2017; 4:39pm
URL: https://forum.world.st/OSProcess-fork-issue-with-Debian-built-VM-tp4947326p4949044.html
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