Posted by K K Subbu on Jun 03, 2017; 4:32pm
URL: https://forum.world.st/OSProcess-fork-issue-with-Debian-built-VM-tp4947326p4949174.html

 
On Saturday 03 June 2017 03:27 AM, Eliot Miranda wrote:
>
> Over my dead body.  The make must *NEVER* be done like this.  The
> problems are many:

Ouch! :-). Please don't take my example too literally. Smalltalk does
not have a concept of a file-based compilation unit like C, so I had to
use an extension to denote a collection of st code that goes into
generating a .c compilation unit. I may well have used a .st or .zip for
source code.

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

This is not the first time C-code gets generated on the fly. This
technique has been used by Lex, Yacc etc. since early 70s. Bison
generates a FSM interpreter in C from a Yacc spec. My example makefile
segment deleted the file, but it can also cache it for debugging.

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

The image is just a smalltalk app that translates slang to C. It does
not have to be regenerated in every build anymore than gcc or cmake. In
earlier posts, I had floated the idea of a bootstrap VM - a st machine
with a built-in image to build and launch larger VMs. It can even be a
separate project.

The .st code has to be translated to C at some time. If it is done
within a single VM, then we won't be able to exploit multi-cores. With
an st2c app, we can translate in parallel for a quicker build.

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

Anyway, my point is that only the smalltalk "compilation unit" should be
under version control. If a .c file is generated from it, there is no
need to subject it to version control. It can continue to remain in a
cache. Like the way we preserve .i (preprocessed) or .s (assembly) files
for debugging .c code but never check-in these i. or .s files.

Okay, I had no idea I was stepping into a minefield of raw nerves here
;-). I will step back from these threads and do some prototyping and
come up with specific code changes. The code seems to have grown too
large for a lone hobbyist but it is still worth a try.

Regards .. Subbu