Smalltalk - Re: OSProcess fork issue with Debian built VM

Smalltalk › Squeak › Squeak VM

Re: OSProcess fork issue with Debian built VM

Posted by Eliot Miranda-2 on Jun 02, 2017; 9:42pm
URL: https://forum.world.st/OSProcess-fork-issue-with-Debian-built-VM-tp4947326p4949091.html

On Fri, Jun 2, 2017 at 9:54 AM, K K Subbu <[hidden email]> wrote:

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

Over my dead body. The make must *NEVER* be done like this. The problems are many:

- the VM so produced is undebuggable. There is no source for FooPlugin.c; it has been deleted

- the build is slow; building a VMMaker image (the necessary prerequisite for st2c) takes a long time, mush longer than the st2c step

- unless FooPlugin.mcz is versioned then the VM so produced is unversioned and if FooPlugin.mcz /is/ versioned then there's no reason why the plugin can't be produced using the normal workflow, generate C source, check it in to opensmalltalk/vm, build, and that way we have a versioned entity and break the dependency of builds requiring VMMaker

Look, I just spent several years persuading the Paro community that generating source and then building was a really bad idea and they should shelve it and now someone is trying to bring it back. No, no, and thrice times, no.

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.

_yes_. _there_. _is_.

Regards .. Subbu

_,,,^..^,,,_

best, Eliot