[Vm-dev] building plugins outside the tree

[K K Subbu]

On Thursday 15 March 2018 09:42 AM, Eliot Miranda wrote:
>     In a vm build, how do I generate the necessary header files and
>     libraries to be able to build plugins later outside the source tree?
> 
> 
> Not sure I understand the question.  All the include files are in the 
> platforms (platforms/Cross/vm & platforms/Cross/plugins/*/*.h) and 
> relevant source tree.  So if you look at the include paths for a build 
> that'll give you the relevant includes.
The src tree combines headers needed to build vm from those needed for 
plugins. Most of the build time is spent on plugins. If the build 
process is split into four+ stages:

first-stage(buildconfig, $VMDK) -> $VMDK/include/, $VMDK/include/$PLAT, 
$VMDK/lib/, $VMDK/lib/$PLAT, $VMDK/lib64/, ....

second-stage($VMDK) - update the above with vm-specific files (say 
sqst.h, sqcog.h sqspur.h, libstvm.a, libcog.a libspur.a etc). $VMDK 
contents are packaged for developers (say libostvm-dev).

third-stage($VMDK) - for each plugin do build plugin using headers and 
libraries in $VMDK/. install header and libraries under $VMDK/. This 
would consume most of the build time, so it could be done in parallel or 
even outside the source directory at a later date. The build would 
depend only on files in $VMDK. Each plugin could choose its code 
structure, platforms and makefiles. Internal plugins would be generated 
in both obj and DLL while external plugins would be DLLs only.

fourth-stage($VMDK with internal plugins) -> squeakvm binary.
   Install libostvm-dev and the dependent external plugin packages. 
Generate multiple headless or GUI launchers and platform-specific 
packages and main package (say ostvm).

> f you're building a plugin you 
> *have* to build different versions for V3 (the original pre-Spur VM), 
> 32-bit Spur and 64-bit Spur.  So for example you'll see that 
> src/vm/interp.h spursrc/vm/interp.h and spur64src/vm/interp.h all differ 
> slightly.  So, other than writing a plugin-specific source file, e.g. 
> platforms/Cross/plugins/FilePlugin/FilePluginh) and 
> platform-and/or-library-specific include files, everything else should 
> be taken from the opensmalltalk-vm source tree.

I see plugins falling into two types - algorithms (e.g. BitBlt) and 
device reifiers (e.g. SoundPlugin). Source level coupling crimps device 
plugin developers. Device plugins tend to be small and the overhead of 
doing a full build is very high. Also, in embedded or IoT deployments, 
the life cycle for plugins can be very different from that of the main 
VM. So it is imperative that they be decoupled from VM build process 
through an explicit SDK.

Regards .. Subbu