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