[Vm-dev] building plugins outside the tree

Eliot Miranda eliot.miranda at gmail.com
Thu Mar 15 19:18:04 UTC 2018


Hi Subbu,

On Thu, Mar 15, 2018 at 12:11 AM, K K Subbu <kksubbu.ml at gmail.com> wrote:

>
> 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.
>>
>
Are you proposing we support this VMDK idea?  Ain't going to happen.  No
cycles.  If I'm misunderstanding then what is VMDK?  And what are sqst,h
sqcog.h sqspur.h?  Look if you're proposing to evolve the build system then
you're going to have to drive that process and you'll get push back because
- what we have works
- most of us are busy developing within that framework and busy developing
useful things
- rearranging things to make things conceptually clearer for newbies is a
laudable goal but expensive and has a very high opportunity cost



> 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
>



-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180315/6f1eaf29/attachment-0001.html>


More information about the Vm-dev mailing list