CMMaker.oscog to fork or not to fork, that! is the question

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

CMMaker.oscog to fork or not to fork, that! is the question

Hi Eliot and David and Tim.

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)
While I am leaning towards a fork of the CMMakeVMaker work on Pharo, I will defer to you folks on that decision.

Below are notes I had made a week ago about why I was leaning that way. 

-----begin notes I made a week or so ago----

For development purposes I am leaning towards creating a CMakeVMMaker.oscog clone of the existing CMakeVMMaker and incrementally adding platform/interpreter configurations starting with
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.

The Pharo environment (very clean, btw) has three layers to it (from top down they are).

1. PharoVMMaker
2. CMakeVMMaker
3. Source Tree and scripts from github.

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.
Launching the resulting generator.image you  are presented a workspace with scripts invoking 1) PharoVMMaker which is a "wrapper" or "interface" to 2) CMakeVMMaker.
This generates the sources and CMake files and from there you go to the build directory and build

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.

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

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. 

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

4. Assuming I can actually do this thing, I do not think a merge of the two projects would be too difficult

---end notes I made a week or so ago---

Please let me know your decision. 




VM-beginners mailing list
[hidden email]