Sounds good.There are three VM configurations.
Assert configurations include assert code with -01 optimization
Debug configurations include assert code with no optimization.
Production has asserts removed by the preprocessor.
a and ast are prefixes for assert.
d and dbg are prefixes for debug.
t suffix is for "threaded" and means that these VMs have the threaded heartbeat, with the others using the problematic itimer heartbeat.
mt stands for multi-threaded, the experimental non-blocking FFI VM.
You much prefer a top level build.OS/WordSize/Processor directory with a HowToBuild file that handles make, make debug and make assert builds.
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
on cygwin the one makefile cygwinbuild/Makefile creates build buildmt builddbg et al.
Then in each non-autoconf build directory have a lang/vmarch/mmarch directory
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|newspeak][stack |cog | sista |][v3 | spur] [2!]x[3!]x[2!] = 24 directories
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.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.
build.linux32x86/
...
squeak.stack.v3
...
...
build.linux32x86/squeak.stack.v3
...