[Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.126.mcz

[Holger Freyther]

> On 21 Jun 2016, at 02:02, gettimothy <gettimothy at zoho.com> wrote:
> 
> Hi Holger.

Good Morning tty,


> The git C source code is really located in the Smalltalk image with VMMaker.oscog installed. The engineer (Eliot) develops the VM in Smalltalk using Smalltalk and then outputs the C code 
> from Smalltalk.  The engineer then uses git to "upload" that C code to the git server.
> 
> The CMakeVMakerSqueak does the same thing. It stores CMake Configurations as objects and then writes that information to standard CMake files in a directory structure that mimics the C directory structure.
> The CMake build tree can then be uploaded the same way.

I have only seen the CMake generation in Pharo and this single commit but from my point of view the VM and the CMake code seems very different:

* The VM code is Smalltalk code and primarily developed with the simulator(?). We do not have a CMake simulator and I think it would not help to build one (the issues to expect are different compiler versions, flags, include paths, libraries, etc.)

* The VM code is Smalltalk code as it provides a high level of abstraction. At least with the CMake generation in the PharoVM the level of abstraction is string concatenation. One CMakeLists.txt to target Unix and Windows will probably be _smaller_ than the Smalltalk subclasses (and metadata) to generate the variants. We can look at webkit, I think their cmake system targets {Gtk, EFL}x{OSX, Linux, FreeBSD, Windows, Haiku}x{x86, amd64, mips, ARMv5, THUMB2}x{tons of options}. With Pharo I felt the actual difference between building for Linux and FreeBSD was smaller than the amount of code (inheritance hierarchy, etc) needed in Smalltalk (and disabling X11 is no attribute of FreeBSD)


* The VM code is debugged in Smalltalk (through the Simulator) while cmake will be trial-and-errored on the actual build environment ($EDITOR CMakeLists.txt CTRL+Z make fg repeat). Only if that works the change will be fed back into the image and then one needs to check if it generated the same CMakeLists.txt as the one, one edited by hand and then try again.


> The model for the CMakeLists.txt is taken directly from Ian's code. Stated differently, Ian's CMake code is stored in Smalltalk.

In 2014/2015 I built the PharoVM on FreeBSD and the pain came from fighting with the code in the image and not cmake itself.

Make it possible to generate the source in one directory and compile it in another.
https://github.com/pharo-project/pharo-vm/commit/4ee7ca5666b74e0540ad75dd6350db33ffc04e7f

Add/Fix FreeBSD generator and disable X11 backend (not included in the 32bit compat and not necessary for my server deployment).
https://github.com/pharo-project/pharo-vm/commit/216f47df008d0f73d24519bc3025ed15f605653f


> 480 distinct build configurations that need supporting.

yeah that is a lot but I think the memory managers, the type (debug, assert, release, etc) and stack/cog can be managed as options with a single cmake file?


> IF the community decides that it is EASIER to work with just CMake Scripts and maintain those by hand, I am fine with that.
> If the community decides that it is BETTER to store them in Smalltalk, I am fine with that too.

sure.


have a nice week
	holger