[Vm-dev] CMMaker.oscog to fork or not to fork, that! is the question

[David T. Lewis]

Hi tty,

I think that you are outlining a reasonable way to set up a build system,
but if your objective is to get oscog and trunk VM builds to use a common
build system based on Cmake, and if you want Ian and Eliot to adopt that
approach, then I think you may be taking the long way around the problem.

The platforms source tree is maintained in Subversion, not in git. The
Cmake code that is used to set up the build is maintained along with the
platform sources (e.g unix/plugins/FilePlugin/config.cmake goes with
unix/plugins/FilePlugin). Those cmake scripts are also maintained in
Subversion, such than any Cmake snippet that may be needed to customize
the build for unix/plugins/FilePlugin is maintained in Subversion along
with the related platform sources.

It is certainly possible maintain the sources in git rather than Subversion,
and it is also possible to generate the Cmake scripts from a Squeak (Pharo)
image, thereby moving the version management into Monticello rather than
Subversion. Both of these are possible, and the Pharo VM build demonstrates
this quite nicely.

I am not going to try to argue that one approach or another is better (I do
have opinions on the matter, but we are not suffering here from a shortage
of opinions). But if your objective is to get oscog and trunk VM builds to
use a common build system based on Cmake, then developing another build
system may not put you on a fast path toward that objective.

Dave


On Tue, May 06, 2014 at 06:19:26PM -0700, gettimothy wrote:
>  
> 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. 
> 
> 
> 
> 
> cordially,
> 
> 
> 
> 
> tty
> 
> 
> 
> 
> 
> 
> 
> 
> :
> 
> 
> 
> 
>