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

[gettimothy]

Hi Holger.

Whatever works for the team is fine by me. However, let me throw this out there.

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.

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

Now, this seques into a VERY IMPORTANT POINT...

I think the CMake output I currently generate needs to be looked at with a critical eye and changes improvements made from a strictly CMake perspective (Like Ian did).
I can then take those changes and store them in the CMakeVMMakerSqueak (if you want me to; we can discuss some ideas why it may make sense)

Building CMakeLists.txt for Windows 32, Windows 64 MacOs, OSX, ARM6 ARM7 , Linux 32, Linux 64, Linux 62w32libs, SunOS, Plan9...etc. needs to be done too. 

Consider also the sheer scope of the CMakeLists.txt that need to be developed.

in the Cog directory tree are build directories. Taking the build.linux32x86 directory as an example, we have a directory tree that looks like this:

build.linux32x86/
|-- newspeak.cog.spur
|   |-- build
|   |-- build.assert
|   |-- build.assert.itimerheartbeat
|   |-- build.debug
|   |-- build.debug.itimerheartbeat
|   `-- build.itimerheartbeat
|-- newspeak.cog.v3
|   |-- build
......etc... .

The FORM of this layout is  :

build.[PLATFORM]/
|-- [Language].[VM].[Memory Manager]/
|   |-- [BuildType]


So looking at the combinations of [PLATFORM][Language].[VM].[Memory Manager] [BuildType] you have

[Windows 32, Windows 64 MacOs, OSX, ARM6 ARM7 , Linux 32, Linux 64, Linux 62w32libs, SunOS, Plan9...etc][squeak, newspeak] [stackVM cogVM][V3 Spur][build build.assert, etc....]
[10 (at least) platforms] x [2 languages] x [2 VMs] x[2 Memory Models] x [6 build types] =

480 distinct build configurations that need supporting.


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.


cheers,

tty







 












---- On Mon, 20 Jun 2016 16:06:28 -0400 Holger Freyther <holger at freyther.de> wrote ---- 

 
 
> On 18 Jun 2016, at 23:28, commits at source.squeak.org wrote: 
> 
> 
> Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: 
> http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.126.mcz 
 
Hi, 
 
I might be teared and feathered but what would it take to maintain the CMakeLists.txt directly in git and not of generate them from Smalltalk? 
 
>From my limited point of view it seems cmake supports targeting multiple platforms/configurations from within the CMakeLists. And when trying to build the PharoVM on FreeBSD I had a lot of trouble[1] and waited[2] a bit too much. 
 
kind regards 
 
    holger 
 
 
 
[1] Trouble in the sense that the generated paths were absolute, that some CFLAGS didn't apply to the compiler used. 
 
[2] I seem to have failed to just generate the CMakeLists.txt/* and decided to generate everything which took some time. E.g. the files not being truncated before they are written to




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