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.