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