<div dir="ltr">Hi Timothy,<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 27, 2014 at 5:01 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><u></u><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif">
Hi Eliot<br><div><br>>a and ast are prefixes for assert. There are three VM configurations. Debug and Assert include assert code, with the Assert VMs being optimized with -O1 (asserts are slow to evaluate and a little optimization can really help). Debug VMs are entirely unoptimized (and hence crawl). >The third is production where asserts are eliminated by the preprocessor.</div>
<div>>Obviously I should be consistent and withe ruse a or ast, not both (and the same for d/bg). <strong>I'm about to revise the whole build directory stricture anyway to make it much more consistent, but I've yet to find the time.</strong></div>
<div><strong><br></strong></div><div>If you have time to give me that naming convention, I will build that directory structure for you and send it to you as a tarball, complete with the existing files so it saves you some time there.</div>
</div></div></blockquote><div><br></div><div>That's a fabulous offer. Thanks. </div><div><br></div><div>I was thinking the right way to do this is to</div><div>a) have all the build directories at the same level (right now some the Cog builds are in Cog/macbuild et al but every other build is one or two levels down, e.g. unixbuild/bld nscogbuild/linuxbuild/bldt)</div>
<div>b) have a consistent naming to ease the writing of scripts</div><div>c) try and keep the hierarchy shallow to avoid lots of ../../../paths</div><div><br></div><div>But a) isn't possible given the current autoconf layout. On unix using autoconf one has to have an additional level to accomodate the production, assert and debug ("pad") builds.</div>
<div><br></div><div>So...</div><div><br></div><div>At the top level have a build.OS/WordSize/Processor directory, which means currently</div><div><br></div><div>build.win32x86</div><div>build.macosx32x86</div><div>build.linux32x86</div>
<div><br></div><div>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, and on cygwin the one makefile cygwinbuild/Makefile creates build buildmt builddbg et al. Otherwise I suppose one could add</div>
<div><br></div><div>build.linux32x86dbg</div>build.linux32x86ast</div><div class="gmail_quote"><br></div><div class="gmail_quote">or just buckle under and use</div><div class="gmail_quote"><br></div><div class="gmail_quote">
build.linux32x86/bulld</div>build.linux32x86/build.assert</div><div class="gmail_extra">etc<br><div class="gmail_quote"><br></div><div class="gmail_quote">? But I much prefer the single directory and then issue different make commands to get the different versions:</div>
<div class="gmail_quote"> make</div><div class="gmail_quote"> make assert</div><div class="gmail_quote"> make debug<br><div><br></div><div>Then in each non-autoconf build directory have a lang/vmarch/mmarch directory, where lang is either squeak or newspeak, vmarch is either stack, cog or sista, and mmarch is either v3 (the current ObjectMemory) or spur. Hence:</div>
<div><br></div><div>squeak.stack.v3</div><div>squeak.stack.spur</div><div>squeak.cog.v3</div><div>squeak.cog.spur</div><div>squeak.sista.v3</div><div>squeak.sista.spur</div><div>newspeak.stack.v3</div><div>newspeak.stack.spur</div>
<div>newspeak.cog.v3</div><div>newspeak.cog.spur</div><div>newspeak.sista.v3</div><div>newspeak.sista.spur</div><div><br></div><div>Then there would be a single HowToBuild in each top-level build dir explaining how to build on that platform.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif">
<div><span style="font-size:10pt">>>The "t" suffix is for "threaded" and means that these VMs have the threaded heartbeat, with the others using the problematic itimer heartbeat. Alas older linux kernels don't allow the threaded heartbeat, but once we're not interested in supporting older then 2.6.14 (IIRC) then they can be dropped.</span><br>
</div><blockquote style="border-left-width:1px;border-left-style:solid;border-left-color:rgb(0,0,255);padding-left:6px;margin:0px 0px 0px 5px"><div dir="ltr"><div><div> </div></div></div></blockquote><div><br></div><div>Is 'mt' is that the same as 't' ?</div>
</div></div></blockquote><div><br></div><div>No. mt stands for multi-threaded, the experimental non-blocking FFI VM. </div><div><br></div><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>Hope this isn't entirely opaque.</div></div><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>