<div dir="ltr">Hi Subbu,<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 15, 2018 at 12:11 AM, K K Subbu <span dir="ltr"><<a href="mailto:kksubbu.ml@gmail.com" target="_blank">kksubbu.ml@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Thursday 15 March 2018 09:42 AM, Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    In a vm build, how do I generate the necessary header files and<br>
    libraries to be able to build plugins later outside the source tree?<br>
<br>
<br>
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.<br></blockquote></span></blockquote><div><br></div><div>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</div><div>- what we have works</div><div>- most of us are busy developing within that framework and busy developing useful things</div><div>- rearranging things to make things conceptually clearer for newbies is a laudable goal but expensive and has a very high opportunity cost</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></span>
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:<br>
<br>
first-stage(buildconfig, $VMDK) -> $VMDK/include/, $VMDK/include/$PLAT, $VMDK/lib/, $VMDK/lib/$PLAT, $VMDK/lib64/, ....<br>
<br>
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).<br>
<br>
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.<br>
<br>
fourth-stage($VMDK with internal plugins) -> squeakvm binary.<br>
  Install libostvm-dev and the dependent external plugin packages. Generate multiple headless or GUI launchers and platform-specific packages and main package (say ostvm).<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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/FilePl<wbr>ugin/FilePluginh) and platform-and/or-library-specif<wbr>ic include files, everything else should be taken from the opensmalltalk-vm source tree.<br>
</blockquote>
<br>
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.<br>
<br>
Regards .. Subbu<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>