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

Eliot Miranda eliot.miranda at gmail.com
Fri Jun 2 21:57:27 UTC 2017


On Fri, Jun 2, 2017 at 9:54 AM, K K Subbu <kksubbu.ml at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170602/c7ad9fea/attachment-0001.html>


More information about the Vm-dev mailing list