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