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

[gettimothy]

Hi Holger,

Good morning.


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

 Yes and agreed.




* 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.
 
The Pharo code, yes. I found no benefit in string concatenation, and I found it needlessly confusing....so...I forked the project to use CMakeTemplates instead. 
CMakeTemplates are wrapper objects around CMake constructs--string concatenation and command output is handled by the template

If you have ever programmed in Seaside, you know how easy it is to use Templates (The Seaside idiom is Components)  to compose web-pages. Templates are  objects that wrap CMake commands/etc.
Generating valid CMake is now a matter of adding CMakeTemplates to a collection then asking those templates to write their content to a stream.
For the programmer, the debugging is very easy and the composing is very intuitive. 

There is no string concatenation on the developer's part.



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

1. the current Smalltalk code is too complicated to maintain for a newbie. I am currently working on a Terse Help Topic for setting up a  "linux 64x64 squeak.cog.spur build " component. 
With the release of the Terse guide, I will be in an "official" alpha release.

I believe a goal should be to radically trim and normalize the CMake generation part of the framework. The current generation is handled in about 3 places with the bulk in VMGenerator>>generateBytemplate:

NO PAIN is the goal. 
CMake DRIVES THE PROCESS is the MOTTO.


2 Here is what I am seeing from my work writing the documentation. There appear to be about  generic steps. 

1 Identify your platform and base configuration
2. Subclass it.
3. Set up directory paths 
4. Set up Compiler Flags (-g -01 
5. Set up Linker flags   (now -foo)
6. Set up Compiler Directives (-D FOO -D BAR
7. Set up librarires
8 . Choose plugins
9. Generate CMake.
10 Debug CMake.


The Generators have debugging tracers in them to identify where the generated CMake code was written from--

SqueakLinux64x86w32CompatBuilder                                                                      <-Platform specific facade to the configurations
    configureA: #Linux64x86w32BitSqueakCogSpurConfig forBuildType:#build;             <-each configuration can handle all build types (if they are coded, just set different flags based on #buildType and the code architecture should invoke the correct ones for the build)
    enableMessageTracking: true;                                                                             <-toggle debugging messages
    generateByTemplate.                                                                                           <-collect and output using the CMakeTemplates



The command above generates CMake that builds a working CMake build tree parallel to the existing build tree that generates a working squeak.cog.spur vm. 

Once these are setup, and (I hope and think) with the documentation in place, adding an entirely different platform or tweaking an existing platform should be less than 1/2 hour job.



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


 
Done. The CMakeVMMaker for squeak generates a parallel structure on the fly to the existing oscogvm tree.
for example: build.linux64/foo becomes cmake.build.linux64/foo  w/ no changes to the existing stuff.
Similarly the "products" directory becomes "cmake.products" again, parallel to the existing structure.





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 
 
 My solution is, subclass an existing 32Bit compat Configuration. Override one method (whatever tells the compiler to not build in X11)
Override another that tells what plugins to use. It automatically supports all buildTypes the parent has


I think a good addition would be options to tell a Configuration what additional or new "flags" it should use


Something like:

SqueakLinux64x86w32CompatBuilder     
    configureA: #Linux64x86w32BitSqueakCogSpurConfig forBuildType:#build;
    withoutPlugin: "X11"
    AddCFlags: #(...)
    RemoveCFlags: #(...)
    
    etc...
    
    enableMessageTracking: true;                                                               
    generateByTemplate.                                                                            

 (This would be an awesome feature) I will add it to my todo list.





cheers,

tty




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/e5fae856/attachment.htm