<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style='font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;'>Hi Holger.<br><br>Whatever works for the team is fine by me. However, let me throw this out there.<br><br>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 <br>from Smalltalk. The engineer then uses git to "upload" that C code to the git server.<br><br>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.<br>The CMake build tree can then be uploaded the same way.<br><br>The model for the CMakeLists.txt is taken directly from Ian's code. Stated differently, Ian's CMake code is stored in Smalltalk.<br><br>Now, this seques into a VERY IMPORTANT POINT...<br><br>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).<br>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)<br><br>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. <br><br>Consider also the sheer scope of the CMakeLists.txt that need to be developed.<br><br>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:<br><br>build.linux32x86/<br>|-- newspeak.cog.spur<br>| |-- build<br>| |-- build.assert<br>| |-- build.assert.itimerheartbeat<br>| |-- build.debug<br>| |-- build.debug.itimerheartbeat<br>| `-- build.itimerheartbeat<br>|-- newspeak.cog.v3<br>| |-- build<br>......etc... .<br><br>The FORM of this layout is :<br><br>build.[PLATFORM]/<br>|-- [Language].[VM].[Memory Manager]/<br>| |-- [BuildType]<br><br><br>So looking at the combinations of [PLATFORM][Language].[VM].[Memory Manager] [BuildType] you have<br><br>[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....]<br>[10 (at least) platforms] x [2 languages] x [2 VMs] x[2 Memory Models] x [6 build types] =<br><br>480 distinct build configurations that need supporting.<br><br><br>IF the community decides that it is EASIER to work with just CMake Scripts and maintain those by hand, I am fine with that.<br>If the community decides that it is BETTER to store them in Smalltalk, I am fine with that too.<br><br><br>cheers,<br><br>tty<br><br><br><br><br><br><br><br> <br><br><br><br><br><br><br><br><br><br><br><br><div class="zmail_extra"><div id="1"><br>---- On Mon, 20 Jun 2016 16:06:28 -0400 <b>Holger Freyther <holger@freyther.de></b> wrote ---- <br></div><blockquote style="border-left: 1px solid #0000FF;padding-left: 6px; margin: 0 0 0 5px"><div> <br> <br>> On 18 Jun 2016, at 23:28, <a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a> wrote: <br>> <br>> <br>> Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: <br>> <a href="http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.126.mcz" target="_blank">http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.126.mcz</a> <br> <br>Hi, <br> <br>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? <br> <br>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. <br> <br>kind regards <br> <br> holger <br> <br> <br> <br>[1] Trouble in the sense that the generated paths were absolute, that some CFLAGS didn't apply to the compiler used. <br> <br>[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</div></blockquote><br></div><br></div></body></html>