Hi Timothy,


On Tue, May 27, 2014 at 5:01 AM, gettimothy <gettimothy@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