CMakeVMMakerSqueak ready for initial testing.

Hi All

I have set up my home computer/domain with svn for initial testing of the CMakeVMMakerSqueak stuff.

svn co http://www.svn.menmachinesmaterials.com/Cog/Cog/

svn co http://www.svn.menmachinesmaterials.com/Cog/mcz

The Cog branch is a co of Eliot's work from today.

The mcz's are the code I have ported; upon acceptance I can move them up to squeak's site.

cd Cog/image

./buildsqueakcmakeimage.sh -h   (will get you usage. The script is a consolidation of Eliot's buildsqueakX.sh scripts)

I have put in a README.buildsqueakcmakeimage.sh that may be of help.

1. Cog stuff is as follows (These will require you manually loading the CMakeVMMakerSqueak-tty-x.mcz from monticello for now. it will be automated should you choose to roll this live)

 ./buildsqueakcmakeimage.sh -c 4.5  (think "cog" for -c) sets up just like Eliot's buildsqueak45image.sh but includes the CMakeVMMaker currently at gemstone and adds a Workspace with some configurations)

  ./buildsqueakcmakeimage.sh -c 4.6  (same as above, but for 4.6 during my testing, this broke sometimes)

Running the script will create a cogVMMaker directory.

For now, copy the .mcz files from the svn co ..mcz... you did to the package_cache in cogVMMaker/Squeak-xyz.app/Contents/Resources/package_cache/     

While you are in the neigborhood, cd to cogVMMaker/Squeak-xyz.app/Contents/Reources/oscogvm/ and do a ls.

You should see some cmake_*build directories there. This is a parallel tree to the standard GNU stuff from which you will be running "source build.sh" to kick off the CMake builds.

cd into cogVMMaker/Squeak-xyz.app/ there should be a  squeakCogVMMaker.sh to run that will launch your new pre-configured image.

launch Monticello and load the latest CMakeVMMakerSqueak-tty

There should be a workspace titled CMakeVMMakerSqueak with some configurations scripts.

Discussion of the code follows 2. below.

3. Discussion of the CMMakeVMMakerSqueak classes.

Due to the layout of the Pharo stuff in CMMakeVMMaker, I was not able to create a Squeak-only subclass tree of the configurations. 

Also, I realized late in the game that there are some false-starts in the pharo design involving the inconsistent use of Traits and Builders. This inconsistency is realized in the Squeak code as well.

Regarding the traits, you will see some stupid stuff in SqueakStackUnixConfig (CMakeVMMakerSqueak-Unix category)  where including the trait in the subclasses results in super calls to where the code is. 

Regarding the builders, you will see that if you start with the Unix stuff, a builder exists (and can be) utilized to power the configs. As the coding progressed, it became apparent that the builders are not necessary as the configs can be invoked directly.

Ok, that's the yuck, lets get you rolling with this stuff.

Running the pre-configred image you will see a CMakeVMMkaerSqueak workspace. Classes that end in Builder are builders and classes that end in Config are Platform Configurations

Find your platform (unix, windows, mac, vax, pdp11...) under CMakeVMMakerSqueak-Platform and (usally) the first config is an "abstract" class (things get stupid in unix land due to the traits, but its not too embarassing).

Under those top classes are concrete configs. Of note in them are the defaultExternalPlugins and defaultInternalPlugins methods. If you look at them you can see you can specify what you need/want. (it gets more flexible with other methods in subclasses, but its a good starting point)

Pick the config you want (SqueakStackUnixDebugConfig in the examples below) and run one of two things: generate or generateWithSources.

SqueakStackUnixDebugConfig generate

will (very quickly) put the cmake config files in the Contents/Resources/oscogvm/cmake_*build directory corresponding to your platform  (look for the buildDirName method on your superclass)

you then cd to that directory and invoke the build.sh script and you should compile against the sources from the svn checkout.

SqueakStackUnixDebugConfig generateWithSources invoked VMMaker to generate the sources before generating the CMake files as above.

Finally, there are Builders that do the above, and frankly , I don't think we need them.

For example in CMakeVMMakerSqueak-Builder SqueakStackVMBuilder  buildSlackwareUnix64w32LibsNoGL you see the wrapper code that invokes the appropriate Config class.

buildSlackwareUnix64w32LibsNoGL
      SqueakStackUnix64w32CompatLibsSlackwareNoGLConfig new
            addExternalPlugins: #( SqueakSSLPlugin );
            addInternalPlugins: #( UnixOSProcessPlugin );
            generateSources;

            generate.

That should get things started. 

Other classes of interest are the CMakeVMMkaersqueak generators: CMakeVMGeneratorForSqueak and CMakePluginGeneratorForSqueak these are essentially a compatiblility layer for the generators

I will leave my computer running tonight (I usually turn it off when I am away from it)

My brain is a bit fried, so in-depth questions and discussions may have to wait until tomorrow.

cheers.

tty