<div dir="ltr">Hi Timothy,<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 28, 2014 at 8:15 AM, gettimothy <span dir="ltr"><<a href="mailto:gettimothy@zoho.com" target="_blank">gettimothy@zoho.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><u></u><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif">Hi Eliot,<br><br>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.<br>
<em>I list my concerns and comments in italics</em> among your points.<br><br><br><br><blockquote style="border-top-color:rgb(204,204,204);border-left-color:rgb(204,204,204);border-right-color:rgb(204,204,204);border-bottom-color:rgb(204,204,204);border-top-width:1px;border-left-width:1px;border-right-width:1px;border-bottom-width:1px;border-top-style:solid;border-left-style:solid;border-right-style:solid;border-bottom-style:solid;padding-top:7px;padding-right:7px;padding-bottom:7px;padding-left:7px;background-color:rgb(245,245,245)">
<div> There are three VM configurations. <br>Assert configurations include assert code with -01 optimization <br>Debug configurations include assert code with no optimization.<br>Production has asserts removed by the preprocessor.<br>
<br>a and ast are prefixes for assert. <br>d and dbg are prefixes for debug.<br>t suffix is for "threaded" and means that these VMs have the threaded heartbeat, with the others using the problematic itimer heartbeat. <br>
mt stands for multi-threaded, the experimental non-blocking FFI VM. <br><br>You much prefer a top level build.OS/WordSize/Processor directory with a HowToBuild file that handles make, make debug and make assert builds.<br>
<br>build.win32x86<br>build.macosx32x86<br>build.linux32x86</div></blockquote><em>Sounds good. <br><br>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.<br>
</em></div></div></blockquote><div><br></div><div>Yes I like this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif">
<em>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.<br><br>cmake_build.win32x86<br>cmake_build.macosx32x86<br>
cmake_build.linux32x86<br>cmake_build.linux32x86_64<br></em></div></div></blockquote><div><br></div><div>Sounds good.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif"><em>I will also re-name the CMakeVMMakerSqueak XYZConf classes to SqueakBuildWin32x86Conf SqueakBuildMacOsX32x86Conf etc so there is a one-to-one corresponsdence between the<br>
default configuration and its directory. (Customizations can be subclassed off of these defaults and routed whereever by the developer if needed)<br></em><br><br><br><blockquote style="border-top-color:rgb(204,204,204);border-left-color:rgb(204,204,204);border-right-color:rgb(204,204,204);border-bottom-color:rgb(204,204,204);border-top-width:1px;border-left-width:1px;border-right-width:1px;border-bottom-width:1px;border-top-style:solid;border-left-style:solid;border-right-style:solid;border-bottom-style:solid;padding-top:7px;padding-right:7px;padding-bottom:7px;padding-left:7px;background-color:rgb(245,245,245)">
<div> If CMake makes it possible and convenient to create the three "pad" builds in build.linux32x86 then fine. <br>e.g. on mac there's a CoreVM.xcode alongside a CoreMTVM.xcode and they create Assert.app AssertMT.app et al<br>
on cygwin the one makefile cygwinbuild/Makefile creates build buildmt builddbg et al. <br></div></blockquote><br><br><div><em>I don't know. The current pharo/squeak structure just specifies where the build directory is. </em></div>
<div><em>Different configurations overwrite what is in the existing directory.<br></em></div><em>I Did a quick search, I ran into this: <a href="http://stackoverflow.com/questions/7724569/debug-vs-release-in-cmake" target="_blank">http://stackoverflow.com/questions/7724569/debug-vs-release-in-cmake</a>So, I guess the answer is "yes" but it has not been implemented.<br>
I will try.<br></em></div></div></blockquote><div><br></div><div>OK, thanks.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif">
<blockquote style="border-top-color:rgb(204,204,204);border-left-color:rgb(204,204,204);border-right-color:rgb(204,204,204);border-bottom-color:rgb(204,204,204);border-top-width:1px;border-left-width:1px;border-right-width:1px;border-bottom-width:1px;border-top-style:solid;border-left-style:solid;border-right-style:solid;border-bottom-style:solid;padding-top:7px;padding-right:7px;padding-bottom:7px;padding-left:7px;background-color:rgb(245,245,245)">
<div>Then in each non-autoconf build directory have a lang/vmarch/mmarch directory <br> lang is either squeak or newspeak, <br> vmarch is either stack, cog or sista, and <br> mmarch is either v3 (the current ObjectMemory) or spur. Hence:<br>
[squeak|newspeak][stack |cog | sista |][v3 | spur] [2!]x[3!]x[2!] = 24 directories<br>squeak.stack.v3<br>squeak.stack.spur<br>squeak.cog.v3<br>squeak.cog.spur<br>squeak.sista.v3<br>squeak.sista.spur<br>newspeak.stack.v3<br>
newspeak.stack.spur<br>newspeak.cog.v3<br>newspeak.cog.spur<br>newspeak.sista.v3<br>newspeak.sista.spur<br><br>Then there would be a single HowToBuild in each top-level build dir explaining how to build on that platform.<br>
<br><br><div>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.</div><div><br></div></div></blockquote> <br><div><em>I am a bit confused here. Are these top-level directories at the same level as build.os.wordsize.platform? </em></div>
<div><em>i.e:</em><br></div><br><br><blockquote style="border-top-color:rgb(204,204,204);border-left-color:rgb(204,204,204);border-right-color:rgb(204,204,204);border-bottom-color:rgb(204,204,204);border-top-width:1px;border-left-width:1px;border-right-width:1px;border-bottom-width:1px;border-top-style:solid;border-left-style:solid;border-right-style:solid;border-bottom-style:solid;padding-top:7px;padding-right:7px;padding-bottom:7px;padding-left:7px;background-color:rgb(245,245,245)">
<div> <br>build.linux32x86/<br>...<br>squeak.stack.v3<br>...</div></blockquote><br><br><em>or are they sub-directories of it? i.e</em><br><br><br><blockquote style="border-top-color:rgb(204,204,204);border-left-color:rgb(204,204,204);border-right-color:rgb(204,204,204);border-bottom-color:rgb(204,204,204);border-top-width:1px;border-left-width:1px;border-right-width:1px;border-bottom-width:1px;border-top-style:solid;border-left-style:solid;border-right-style:solid;border-bottom-style:solid;padding-top:7px;padding-right:7px;padding-bottom:7px;padding-left:7px;background-color:rgb(245,245,245)">
<div> ...<br>build.linux32x86/squeak.stack.v3<br>...<br><br></div></blockquote><br></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div></div>-- <br>best,<div>Eliot</div>
</div></div>