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.
build.win32x86 build.macosx32x86 build.linux32x86
*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.cmake_build.win32x86cmake_build.macosx32x86cmake_build.linux32x86cmake_build.linux32x86_64*
Sounds good.
*I will also re-name the CMakeVMMakerSqueak XYZConf classes to SqueakBuildWin32x86Conf SqueakBuildMacOsX32x86Conf etc so there is a one-to-one corresponsdence between thedefault 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-cmake 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 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.
*I am a bit confused here. Are these top-level directories at the same level as build.os.wordsize.platform? * *i.e:*
build.linux32x86/ ... squeak.stack.v3 ...
*or are they sub-directories of it? i.e*
... build.linux32x86/squeak.stack.v3 ...
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.