[Vm-dev] building plugins outside the tree
K K Subbu
kksubbu.ml at gmail.com
Tue Mar 20 04:02:30 UTC 2018
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
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
> 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
> 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 :-(
Regards .. Subbu
More information about the Vm-dev