<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style='font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;'><div>Hi Eliot and David and Tim.</div><div><br></div><div>Tomorrow I start the actual Smalltalk coding of the CMake stuff for Squeak. (My shell script that I thought would take 1 day took 5. sigh)</div><div>While I am leaning towards a fork of the CMMakeVMaker work on Pharo, I will defer to you folks on that decision.</div><div><br></div><div>Below are notes I had made a week ago about why I was leaning that way.&nbsp;</div><div><br></div><div>-----begin notes I made a week or so ago----</div><div><br></div><div>For development purposes I am leaning towards creating a CMakeVMMaker.oscog clone of the existing CMakeVMMaker and incrementally adding platform/interpreter configurations starting with</div><div>the Stack Interpreter. Much of the work will be cut-n-paste modifications of the existing work in CMakeVMMaker done by the pharo team as that is the guts of the pharo system.</div><div><br></div><div>The Pharo environment (very clean, btw) has three layers to it (from top down they are).</div><div><br></div><div>1. PharoVMMaker</div><div>2. CMakeVMMaker</div><div>3. Source Tree and scripts from github.</div><div><br></div><div>What is very interesting about pharo is that given 3) a git checkout, you can download, run and configure a new pharo image using a shell script provided with the git source.</div><div>Launching the resulting generator.image you &nbsp;are presented a workspace with scripts invoking 1) PharoVMMaker which is a "wrapper" or "interface" to 2) CMakeVMMaker.</div><div>This generates the sources and CMake files and from there you go to the build directory and build</div><div><br></div><div>I like this approach and will be emulating it, but I do not think it is integrate the Squeak infrastructure into the existing package; here is why.</div><div><br></div><div>1. Squeak source tree from svn is a superset of the tree from git with a slight difference in naming for the default build. Where Squeak has unixbuild, nssprucogbuild, etc, pharo just has build.&nbsp;</div><div>&nbsp; &nbsp; This "probably" has implications for the CMMake script generation that will not suffice for supporting the standard interpreter nor for the other flavors Eliot is developing.</div><div><br></div><div>2. If I attempt to merge the two approaches (git and svn, pharo build tree and squeak build tree) &nbsp;it will clutter the very clean work-flow pharo has.&nbsp;</div><div><br></div><div>3. As I develop this, I would like the squeak community to test-drive what I do. It is not appropriate for me to muddy the existing CMakeVMMaker with dev work</div><div><br></div><div>4. Assuming I can actually do this thing, I do not think a merge of the two projects would be too difficult</div><div><br></div><div>---end notes I made a week or so ago---</div><div><br></div><div>Please let me know your decision.&nbsp;</div><div><br></div><div><br></div><div>cordially,</div><div><br></div><div><br></div><div>tty</div><div><br></div><div><br></div><div><br></div><div><br></div><div>:</div><div><br></div><div><br></div></div></body></html>