[Vm-dev] Naming convetions for Cog unix builds question (abldt, bldt, dbldt, astbldt, asbld etc)

[Eliot Miranda]

Hi Timothy,


On Tue, May 27, 2014 at 5:01 AM, gettimothy <gettimothy at zoho.com> wrote:

>
> Hi Eliot
>
> >a and ast are prefixes for assert.  There are three VM configurations.
>  Debug and Assert include assert code, with the Assert VMs being optimized
> with -O1 (asserts are slow to evaluate and a little optimization can really
> help).  Debug VMs are entirely unoptimized (and hence crawl). >The third is
> production where asserts are eliminated by the preprocessor.
> >Obviously I should be consistent and withe ruse a or ast, not both (and
> the same for d/bg).  *I'm about to revise the whole build directory
> stricture anyway to make it much more consistent, but I've yet to find the
> time.*
>
> If you have time to give me that naming convention, I will build that
> directory structure for you and send it to you as a tarball, complete with
> the existing files so it saves you some time there.
>

That's a fabulous offer.  Thanks.

I was thinking the right way to do this is to
a) have all the build directories at the same level (right now some the Cog
builds are in Cog/macbuild et al but every other build is one or two levels
down, e.g. unixbuild/bld nscogbuild/linuxbuild/bldt)
b) have a consistent naming to ease the writing of scripts
c) try and keep the hierarchy shallow to avoid lots of ../../../paths

But a) isn't possible given the current autoconf layout.  On unix using
autoconf one has to have an additional level to accomodate the production,
assert and debug ("pad") builds.

So...

At the top level have a build.OS/WordSize/Processor directory, which means
currently

build.win32x86
build.macosx32x86
build.linux32x86

If CMake makes it possible and convenient to create the three "pad" builds
in build.linux32x86 then fine.  e.g. on mac there's a CoreVM.xcode
alongside a CoreMTVM.xcode and they create Assert.app AssertMT.app et al,
and on cygwin the one makefile cygwinbuild/Makefile creates build buildmt
builddbg et al.  Otherwise I suppose one could add

build.linux32x86dbg
build.linux32x86ast

or just buckle under and use

build.linux32x86/bulld
build.linux32x86/build.assert
etc

?  But I much prefer the single directory and then issue different make
commands to get the different versions:
   make
   make assert
   make debug

Then in each non-autoconf build directory have a lang/vmarch/mmarch
directory, where lang is either squeak or newspeak, vmarch is either stack,
cog or sista, and mmarch is either v3 (the current ObjectMemory) or spur.
 Hence:

squeak.stack.v3
squeak.stack.spur
squeak.cog.v3
squeak.cog.spur
squeak.sista.v3
squeak.sista.spur
newspeak.stack.v3
newspeak.stack.spur
newspeak.cog.v3
newspeak.cog.spur
newspeak.sista.v3
newspeak.sista.spur

Then there would be a single HowToBuild in each top-level build dir
explaining how to build on that platform.

>>The "t" suffix is for "threaded" and means that these VMs have the
> threaded heartbeat, with the others using the problematic itimer heartbeat.
>  Alas older linux kernels don't allow the threaded heartbeat, but once
> we're not interested in supporting older then 2.6.14 (IIRC) then they can
> be dropped.
>
>
> Is  'mt'   is that the same as 't'  ?
>

No.  mt stands for multi-threaded, the experimental non-blocking FFI VM.

Again on win32 under cygwin and on mac os x under xcode it is easy to keep
the non-mt and mt builds at the same level, sharing a directory.

Hope this isn't entirely opaque.

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140527/61c0b2ba/attachment-0001.htm