[Vm-dev] building plugins outside the tree

[K K Subbu]

On Monday 19 March 2018 11:03 PM, tim Rowledge wrote:
> 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.

You're right. Plugins, particularly those tied to hardware like GPIO on 
Raspberry Pi, need not be multi-platform. This is all the more reason to 
decouple their builds from that of the main vm.

I wasn't really advocating for links. I don't think links are essential 
to decouple *.h and lib files required by plugin build. The early build 
process just needs to "install" these files under the product directory 
instead of leaving them scattered all the vm source tree. These extra 
files can be put into a separate squeakvm-dev package and used only for 
plugin-dev.

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

Great idea! PluginMaker! A new vmmaker package could ship with a vmmaker 
image with all platform-fu and Slang transcoding required for plugin 
builds. If someone wants to build FooPlugin on a specific platform, they 
can use it to generate customized *.h files along with the initial 
fooPlugin.c file.

> We could certainly improve documentation so it is easier to find out 
> what is needed.

I would be interested in contributing here. Any suggestions on existing 
plugins (hardware-related) that can serve as a model or a good starting 
point in squeak wiki?

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

Slang transcoding is easy and convenient, but it requires a working 
VM+image creating a cyclic dependency between making a VM and making a 
plugin. Currently, the dependency is resolved by squishing everything 
into one monolithic, sequential build. I had pursued the idea of modular 
plugins way back in 2009 but got whacked by Cog transition :-(

  http://forum.world.st/Modular-Plugins-td975999.html

Regards .. Subbu