Re: [Vm-dev] Naming convetions for Cog unix builds question (abldt, bldt, dbldt, astbldt, asbld etc)

[gettimothy]

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.


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.win32x86
cmake_build.macosx32x86
cmake_build.linux32x86
cmake_build.linux32x86_64

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.



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
...





Cheers.


tty

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140528/2eef1c84/attachment-0001.htm