[Vm-dev] building plugins outside the tree
K K Subbu
kksubbu.ml at gmail.com
Thu Mar 15 07:11:35 UTC 2018
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
More information about the Vm-dev
mailing list