Hi Timothy,

On Wed, May 28, 2014 at 8:15 AM, gettimothy <gettimothy@zoho.com> wrote:
Hi Eliot,

I have condensed your email into somewhat of a bullet points version. I do have one concern and that is newbie-end-user ease of use.
I list my concerns and comments in italics among your points.

 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.

Sounds good. 

I propose a build.linux32x86_64 to handle the special case of building agianst 32 bit compat libs on debian/slackware.  Yes, it can be done in the x86 directory, but consider the newbie end user who wants to get up and running hacking vm's quickly.

Yes I like this.

I also propose a parallel cmake_build.OS/WordSizeProcessor tree to minimize confusion and traps while we get our heads around and learn the idiosyncracies of CMake.


Sounds good.

I will also re-name the CMakeVMMakerSqueak XYZConf classes to SqueakBuildWin32x86Conf SqueakBuildMacOsX32x86Conf etc so there is a one-to-one corresponsdence between the
default configuration and its directory. (Customizations can be subclassed off of these defaults and routed whereever by the developer if needed)

 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.

I don't know. The current pharo/squeak structure just specifies where the build directory is.
Different configurations overwrite what is in the existing directory.
I Did a quick search, I ran into this: http://stackoverflow.com/questions/7724569/debug-vs-release-in-cmakeSo, I guess the answer is "yes" but it has not been implemented.
I will try.

OK, thanks.

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

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.

I am a bit confused here. Are these top-level directories at the same level as build.os.wordsize.platform?


or are they sub-directories of it? i.e


The latter.  Each top-level build directory corresponds to a host architecture (OS, processor, word size).  Within each top-level build directory are all the variants of VMs that we can build.  That fills out the 2d grid of os/processor vs VM variant.