[Vm-dev] building plugins outside the tree

[Eliot Miranda]

Hi Tim,

On Mon, Mar 19, 2018 at 10:33 AM, tim Rowledge <tim at rowledge.org> wrote:

>
>
>
> > On 19-03-2018, at 4:46 AM, K K Subbu <kksubbu.ml at gmail.com> wrote:
> > [snip]
> > Generating C code is the least of the problem. The complexity is in
> compiling it to a shared library. Hardware plugins face a much bigger issue
> than algorithmic plugins because they have to integrate slang generated
> code with hand-coded and local headers/libs.
>
> You'll have the complexity of the build system whatever you do within a
> C/make world. You need the relevant headers and hand-written code and make
> related files. Nothing is likely to change that much.
> You edit the hand-written code, generate any Slang code from your VMMaker
> image, go to the right directory and type make.
>
> What could we do to make that easier?
>
> I guess *if* everything worked properly on all platforms (which it never
> has and likely never will) we could imagine each plugin directory
> containing links to every relevant file so that the insane complexity of
> paths that look like ../../../../../platforms/unix/sysV4/plugins/WibbleWriter
> could be avoided. That was actually a part of my original plan when I
> started the VMMaker stuff back in ... 2000. Eek. But linking simply didn't
> work across platforms back then and I don't honestly imagine it would work
> neatly now. Andreas insisted on a strange arrangement of files for Window
> because he didn't want to sort out nmake (which was the windows make
> equivalent back then and since I had had some very unpleasant experience
> making it work well enough to build VisualWorks a few years before that I
> couldn't really argue). RISC OS could do links but only really of
> directories. Mac couldn't do links at all, just sometihng I can't even
> remember the name of now, that had to be manually interpreted. Perhaps some
> git magic might make it work so that all the file appear in the plugin
> build directcory?
>
> We could conceivably build a tool in Squeak to drive it all a bit more
> pleasantly, using stuff from OSProcess and CommandTool etc. Platform
> spread, as so often, is a major cause of work here.
>
> We could certainly improve documentation so it is easier to find out what
> is needed.
>
> I'd even argue that we would be better off *not* having copies of the
> generated code publicly available and looking like you can edit them.
> Generating the files from Slang is not really all that time consuming (even
> on a Pi) and you don't have to do all of it every time, and we could
> probably improve detection of when you do.
>

Over my dead body.  Look, the generated sources all start with comments
that say

/* Automatically generated by

they could say

/* Automatically generated by
.....
  DO NOT EDIT
 */

But going back to generating the VM sources every time one wants to build a
VM, having, as Ben points out the possibility of changes in Slang,
variability due to sets changing generated sources, date stamps changing,
etc, etc.  NO!!!!!!!  I can't believe you're serious.


_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180320/134ca778/attachment.html>