<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 6, 2014 at 10:11 PM, Esteban Lorenzano <span dir="ltr"><<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi,<br>
<br>
if I can give an opinion, I would go through making a “SqueakVMMaker”, PharoVMMaker style.<br>
then you don’t need to fork the common base who will still be available for all platforms.<br></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Esteban<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 07 May 2014, at 05:17, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
<br>
><br>
> Hi tty,<br>
><br>
> I think that you are outlining a reasonable way to set up a build system,<br>
> but if your objective is to get oscog and trunk VM builds to use a common<br>
> build system based on Cmake, and if you want Ian and Eliot to adopt that<br>
> approach, then I think you may be taking the long way around the problem.<br>
><br>
> The platforms source tree is maintained in Subversion, not in git. The<br>
> Cmake code that is used to set up the build is maintained along with the<br>
> platform sources (e.g unix/plugins/FilePlugin/config.cmake goes with<br>
> unix/plugins/FilePlugin). Those cmake scripts are also maintained in<br>
> Subversion, such than any Cmake snippet that may be needed to customize<br>
> the build for unix/plugins/FilePlugin is maintained in Subversion along<br>
> with the related platform sources.<br>
><br>
> It is certainly possible maintain the sources in git rather than Subversion,<br>
> and it is also possible to generate the Cmake scripts from a Squeak (Pharo)<br>
> image, thereby moving the version management into Monticello rather than<br>
> Subversion. Both of these are possible, and the Pharo VM build demonstrates<br>
> this quite nicely.<br>
><br>
> I am not going to try to argue that one approach or another is better (I do<br>
> have opinions on the matter, but we are not suffering here from a shortage<br>
> of opinions). But if your objective is to get oscog and trunk VM builds to<br>
> use a common build system based on Cmake, then developing another build<br>
> system may not put you on a fast path toward that objective.<br>
><br>
> Dave<br>
><br>
><br>
> On Tue, May 06, 2014 at 06:19:26PM -0700, gettimothy wrote:<br>
>><br>
>> Hi Eliot and David and Tim.<br>
>><br>
>><br>
>> 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)<br>
>> While I am leaning towards a fork of the CMMakeVMaker work on Pharo, I will defer to you folks on that decision.<br>
>><br>
>><br>
>> Below are notes I had made a week ago about why I was leaning that way.<br>
>><br>
>><br>
>> -----begin notes I made a week or so ago----<br>
>><br>
>><br>
>> For development purposes I am leaning towards creating a CMakeVMMaker.oscog clone of the existing CMakeVMMaker and incrementally adding platform/interpreter configurations starting with<br>
>> 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.<br>
>><br>
>><br>
>> The Pharo environment (very clean, btw) has three layers to it (from top down they are).<br>
>><br>
>><br>
>> 1. PharoVMMaker<br>
>> 2. CMakeVMMaker<br>
>> 3. Source Tree and scripts from github.<br>
>><br>
>><br>
>> 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.<br>
>> Launching the resulting generator.image you are presented a workspace with scripts invoking 1) PharoVMMaker which is a "wrapper" or "interface" to 2) CMakeVMMaker.<br>
>> This generates the sources and CMake files and from there you go to the build directory and build<br>
>><br>
>><br>
>> 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.<br>
>><br>
>><br>
>> 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.<br>
>> 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.<br>
>><br>
>><br>
>> 2. If I attempt to merge the two approaches (git and svn, pharo build tree and squeak build tree) it will clutter the very clean work-flow pharo has.<br>
>><br>
>><br>
>> 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<br>
>><br>
>><br>
>> 4. Assuming I can actually do this thing, I do not think a merge of the two projects would be too difficult<br>
>><br>
>><br>
>> ---end notes I made a week or so ago---<br>
>><br>
>><br>
>> Please let me know your decision.<br>
>><br>
>><br>
>><br>
>><br>
>> cordially,<br>
>><br>
>><br>
>><br>
>><br>
>> tty<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> :<br>
>><br>
>><br>
>><br>
>><br>
>><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>