[Vm-dev] Re: Check new directory structure for RiscOS build (was: [commit][2807] look for plugins.{int,ext,exc} in build, unix/cmake and src; parse plugin lists more robustly)

[Eliot Miranda]

Hi Tim,


On Tue, Nov 19, 2013 at 8:09 PM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> On Tue, Nov 19, 2013 at 04:42:56PM -0800, tim Rowledge wrote:
> >
> > Home At Last! Travel may broaden the mind but it sure wears out the body.
> >
> > So I want to check on the state of CMakeificiation; I saw all the emails
> about assorted build related files go by whilst travelling but an up to
> date summary would be nice. Are we, for example, at a stage where adding
> the faster bitblt plugin to the Pi stack vm can be done? That after all is
> my main immediate aim. I?d do a checkout and try to work it out for myself
> but given that I pretty much threw the towel in for understanding
> autoCmakeconfigMagic (2.15j) it?ll probably be quicker to ask for an
> explanation. If I actually understand it I might even be able to provide
> some doc.
> >
>
> Hi Tim,
>
> I'm not sure I can answer the question regarding the bitblt plugin,
> but with respect to changes to the build conventions, here is an
> attempt at a summary of the changes:
>
> - Generated sources now have the plugins in all in a single directory.
>
> - plugins.int, plugins.ext work the same as before, except that now we
> have a search path convention for finding them in one of possibly three
> locations.
>
> - plugins.ext may optionally be provided as a means of explicitly excluding
> plugins from the build. Probably not of interest for a RiscOS build, and
> somewhat redundant with the "--without-foo" option for Unix CMake, but
> possibly useful and provided for compatibility with the Cog build.
>
> - Search path for the plugins.int/ext/exc files is bld, config, src.
>
> - bld means your own build directory (in which you may have added
> a local plugins.int and/or plugins.ext file).
>
> - config means a location in the platforms tree, for Unix this is
> the platforms/unix/cmake directory. You can ignore this if you do
> not need it.
>
> - src means the directory containing generated sources from VMMaker.
> This may be the generated sources that we are now saving in SVN in
> trunk/src, or it may be the local directory in which you generated
> your own sources from VMMaker. This is the default location for
> plugins.int and plugins.ext if not overridden by a file of the same
> name in bld or config.
>
> - The src directory may contain a full set of generated sources (as
> would generated from a CrossPlatformVMMaker). The build procedure is
> expected to select the modules of interest based on plugins.int/ext/exc.
>
> - Alternatively, the src directly may contain just the sources that
> you generated locally using a VMMakerTool for your own system platform.
> In either case, the build system should be able to use plugins.int/ext
> to identify the internal and external plugins.
>
> - The sqNamedPrims.h header was (and currently still is) generated by
> VMMaker. However, it needs to match the plugins listed in plugins.int,
> which may now be e.g. a hand-edited file in your build directory.
> Therefore it must now be generated by the build process. In the case
> of the Unix CMake build, this is now done by some script code added
> to platforms/unix/cmake/Platforms.cmake (because CMake is already
> figuring out which plugins.int file to use). Something similar may
> be needed for RiscOS if you build from trunk/src.
>
> - VMMaker still generates plugins.int, plugins.ext, and sqNamedPrims.h
> as before. If you are building from locally generated sources from
> a VMMakerTool, the only thing that has actually changed is the directory
> structure in which all plugins are in a single directory.
>

Let me ‘splain…No, there is too much. Let me sum up.

Its inflexible to determine which plugins are included at VM generation
time. Means different generations for different platforms, etc. Mar simpler
to determine it at build time.  That way we can use one set of sources
(possibly under source code control) and build any VM. Instead, determine
which plugins are included, and whether internal or external, at build
time.  So...

1. generate any and all plugins in one place, e.g. src/plugins.
2. in the build directory have plugins.int and plugins.ext decide which
plugins are included and whether they're internal or external.
3. have the build generate sqNamedPrims.h from plugins.int

Hence the base build directory for a unix build on cog contains:

mvm - a script that invokes configure and make install
plugins.ext - which plugins to build external
plugins.int - which plugins to build internal

HTH
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131120/7888f34e/attachment-0001.htm