On 18 Jun 2016, at 23:28, commits@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
On Mon, Jun 20, 2016 at 10:06:28PM +0200, Holger Freyther wrote:
On 18 Jun 2016, at 23:28, commits@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?
That is exactly how Ian Piumarta's CMake build system has been working for the last 6 years or so. It is done with a relatively small amount of CMake scripting code, and has been working reliably with only minimal maintenance since it was first put in place.
My earlier comments on this topic are here (my references to the Subversion repository would now pertain to the new Github repository): http://lists.squeakfoundation.org/pipermail/vm-dev/2014-May/015313.html
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.
Yes, that is the purpose of CMake. It is designed to be a platform independent build tool. If you find yourself creating large quantities of platform specific CMake scripts, it is a sign that something is wrong.
So it certainly does make sense for the CMakeLists to be maintained and versioned along with the source code to which they apply. No need for any tar and feathers IMHO :-)
Dave
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
Hi David Hi Holger
On thinking about this, you guys are probably right.
Unfortunately, I have no interest in that project (I would like to move on to other things)
If you take the output from just one configuration like....
SqueakLinux64x86w32CompatBuilder configureA: #Linux64x86w32BitSqueakCogSpurConfig forBuildType:#build; enableMessageTracking: false; generateByTemplate.
It will generate cmake.build.linux64x86w32BitCompatibility directory structure (in the oscogvm directory under your image directory)
If you then run cmake . it will generate the cmake output.
That is essentially Ian's work generated from CMakeVMMakerSqueak.
Here is my reasoning.
We want source control of the CMake artefacts We want a quick way to create additional build trees .
With the move to GIT, the source control and distribution problems are resolved with git's branch merge etc. It is duplication to do that in Squeak (which is what the CMakeVMMakerSqueak project is) It may be quicker to to create new CMake artefacts in plain scripts.
I think in terms of time, the experiment would prove useful to see if that is the better model for building out the CMake scripts.
If not, I can continue the work on CMakeVMMakerSqueak.
There are a couple more technical issues to fix (how plugins/cmake interact ...?) The CHIEF issue is ease of use and logic to the setup of new configurations for different platforms.
I am currently working on a Terse Guide for setting up a configuration "quickly" and as you can see, there is significant work to it (as Holger mentioned):
NOT DONE setGlobalOptions
IDENTIFY CONFIGURATIONS CATEGORY CMakeVMMakerSqueak-Linux64x64
IDENTIFY ABSTRACT BASE CLASS Linux64x64Config isAbstractBaseClass
IDENTIFY BUILDER SqueakLinux64x64Builder configurationsCategory SqueakLinux64x64Builder availableBuildConfigurations SqueakLinux64x64Builder unAvailableBuildConfigurations
CREATE AND CONFIGURE THE CONFIGURATION FOR BUILDER INTERACTION (must verify/do) Linux64x64Config subclass: #Linux64x64SqueakCogSpurConfig Linux64x64SqueakCogSpurConfig excludeFromBuild ^false Linux64x64SqueakCogSpurConfig class isAbstractBaseClass ^false Linux64x64SqueakCogSpurConfig >> availableBuildTypes
SET UP DIRECTORY PATHS FOR CMAKE OUTPUT (must verify/do) Linux64x64SqueakCogSpurConfig dirBuildPlatform ^self dirLinux64x64 Linux64x64SqueakCogSpurConfig >>dirSource ^self spur64src Linux64x64SqueakCogSpurConfig >> dirBuildLanguageVMMM ^self squeakCogSpur Linux64x64Config >> coreSourcesBuild
NOT DONE setGlobalOptions
IDENTIFY CONFIGURATIONS CATEGORY CMakeVMMakerSqueak-Linux64x64
IDENTIFY ABSTRACT BASE CLASS Linux64x64Config isAbstractBaseClass
IDENTIFY BUILDER SqueakLinux64x64Builder configurationsCategory SqueakLinux64x64Builder availableBuildConfigurations SqueakLinux64x64Builder unAvailableBuildConfigurations
CREATE AND CONFIGURE THE CONFIGURATION FOR BUILDER INTERACTION (must verify/do) Linux64x64Config subclass: #Linux64x64SqueakCogSpurConfig Linux64x64SqueakCogSpurConfig excludeFromBuild ^false Linux64x64SqueakCogSpurConfig class isAbstractBaseClass ^false Linux64x64SqueakCogSpurConfig >> availableBuildTypes
SET UP DIRECTORY PATHS FOR CMAKE OUTPUT (must verify/do) Linux64x64SqueakCogSpurConfig dirBuildPlatform ^self dirLinux64x64 Linux64x64SqueakCogSpurConfig >>dirSource ^self spur64src Linux64x64SqueakCogSpurConfig >> dirBuildLanguageVMMM ^self squeakCogSpur Linux64x64Config >> coreSourcesBuild SystemNavigation browseAllImplementorsOf: #cmakeWriteDirectoriesDotCmake:
SET VM TYPE AND SOURCE INFORMATION (must verify/do) Linux64x64SqueakCogSpurConfig >> setPlatformSourcesBuild:aMaker Linux64x64SqueakCogSpurConfig >> cogitClass ^ StackToRegisterMappingCogit Linux64x64SqueakCogSpurConfig >> interpreterClass ^ CoInterpreter
CMAKE GLOBAL OPTIONS AND NON-STANDARD LOCATIONS HINTS , OS SPECIFIC IDIOMS (possible overrides) x-CPlatformConfigForSqueak >> setGlobalOptionsBuild: aMaker x-SqueakUnixConfig >>cmakePrefixPathBuild x-SqueakUnixConfig >>cmakeIncludePathBuild x-SqueakUnixConfig >>cmakeLibraryPathBuild x-SqueakUnixConfig>>cmakeIncludeModulesBuild x-SqueakUnixConfig >>extraVMSettingsBuild: aMaker
SET COMPILER FLAGS, COMPILER DEFINITIONS, LINKER FLAGS, LIBRARIES (WHAT ELSE?) (must verify/do) Linux64x64SqueakCogSpurConfig >> compilerFlagsBuild Linux64x64SqueakCogSpurConfig >> compilerDefinitionsBuild
(possible overrides) Linux64x64SqueakCogSpurConfig >> externalLibsBuild ^self externalLibraries asOrderedCollection. Linux64x64Config >> externalLibraries (note, this is the Abstract base class, override if you wish) Linux64x64Config >> linkerFlagsBuild (note this is abstract base class, override if you wish) SqueakUnixConfig>>standardIncludesBuild Linux64x64Config >> preferredIncludesBuild
INCLUDE OPTIONAL CMAKE MODULES
SystemNavigation browseAllImplementorsOf: #cmakeWriteDirectoriesDotCmake:
SET VM TYPE AND SOURCE INFORMATION (must verify/do) Linux64x64SqueakCogSpurConfig >> setPlatformSourcesBuild:aMaker Linux64x64SqueakCogSpurConfig >> cogitClass ^ StackToRegisterMappingCogit Linux64x64SqueakCogSpurConfig >> interpreterClass ^ CoInterpreter
CMAKE GLOBAL OPTIONS AND NON-STANDARD LOCATIONS HINTS , OS SPECIFIC IDIOMS (possible overrides) x-CPlatformConfigForSqueak >> setGlobalOptionsBuild: aMaker x-SqueakUnixConfig >>cmakePrefixPathBuild x-SqueakUnixConfig >>cmakeIncludePathBuild x-SqueakUnixConfig >>cmakeLibraryPathBuild x-SqueakUnixConfig>>cmakeIncludeModulesBuild x-SqueakUnixConfig >>extraVMSettingsBuild: aMaker
SET COMPILER FLAGS, COMPILER DEFINITIONS, LINKER FLAGS, LIBRARIES (WHAT ELSE?) (must verify/do) Linux64x64SqueakCogSpurConfig >> compilerFlagsBuild Linux64x64SqueakCogSpurConfig >> compilerDefinitionsBuild
(possible overrides) Linux64x64SqueakCogSpurConfig >> externalLibsBuild ^self externalLibraries asOrderedCollection. Linux64x64Config >> externalLibraries (note, this is the Abstract base class, override if you wish) Linux64x64Config >> linkerFlagsBuild (note this is abstract base class, override if you wish) SqueakUnixConfig>>standardIncludesBuild Linux64x64Config >> preferredIncludesBuild
INCLUDE OPTIONAL CMAKE MODULES
So, I have to ask myself---what type of work makes better sense and includes less work? Directly hacking the CMakeLists.txt themselves? or the above "terse guide"?
Thoughts?
Hi David,
This is a resend of an email I sent earlier.
RE:
---- On Mon, 20 Jun 2016 19:05:23 -0400 David T. Lewis <lewis@mail.msen.com> wrote ----
On Mon, Jun 20, 2016 at 10:06:28PM +0200, Holger Freyther wrote: > > > > On 18 Jun 2016, at 23:28, commits@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? >
That is exactly how Ian Piumarta's CMake build system has been working for the last 6 years or so. It is done with a relatively small amount of CMake scripting code, and has been working reliably with only minimal maintenance since it was first put in place.
My earlier comments on this topic are here (my references to the Subversion repository would now pertain to the new Github repository): http://lists.squeakfoundation.org/pipermail/vm-dev/2014-May/015313.html
> 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. >
Yes, that is the purpose of CMake. It is designed to be a platform independent build tool. If you find yourself creating large quantities of platform specific CMake scripts, it is a sign that something is wrong.
So it certainly does make sense for the CMakeLists to be maintained and versioned along with the source code to which they apply. No need for any tar and feathers IMHO :-)
Dave
> 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
There is a good chance that you and holger are correct. Also, the CMakeVMMakerSqueak itself will need crowd-sourcing to build out the various build types, so, since crowd-sourcing needs to be done, why not do it directly an example CMake build tree (I have 3 that can be generated) and use the git for developing them?
There is significant work remaining to get the CMakeVMMakerSqueak use documented, simplified (and some refactoring in plugins to be done). I would rather avoid that work (and move on to other projects) if the community can make better progress with straight CMake build scripts.
Let me know what your decision is.
cheers,
t
Hi tty,
I am not sure that I can give you the answer you need, but my expectation is that the current build system for Cog/Spur is going to be significantly revised or replaced in the near future. It might make sense for you to wait a bit and see what direction that takes.
Dave
On Sun, Jul 10, 2016 at 07:45:01PM -0400, gettimothy wrote:
Hi David,
This is a resend of an email I sent earlier.
RE:
---- On Mon, 20 Jun 2016 19:05:23 -0400 David T. Lewis <lewis@mail.msen.com> wrote ----
On Mon, Jun 20, 2016 at 10:06:28PM +0200, Holger Freyther wrote: > > > > On 18 Jun 2016, at 23:28, commits@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? >
That is exactly how Ian Piumarta's CMake build system has been working for the last 6 years or so. It is done with a relatively small amount of CMake scripting code, and has been working reliably with only minimal maintenance since it was first put in place.
My earlier comments on this topic are here (my references to the Subversion repository would now pertain to the new Github repository): http://lists.squeakfoundation.org/pipermail/vm-dev/2014-May/015313.html
> 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. >
Yes, that is the purpose of CMake. It is designed to be a platform independent build tool. If you find yourself creating large quantities of platform specific CMake scripts, it is a sign that something is wrong.
So it certainly does make sense for the CMakeLists to be maintained and versioned along with the source code to which they apply. No need for any tar and feathers IMHO :-)
Dave
> 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
There is a good chance that you and holger are correct. Also, the CMakeVMMakerSqueak itself will need crowd-sourcing to build out the various build types, so, since crowd-sourcing needs to be done, why not do it directly an example CMake build tree (I have 3 that can be generated) and use the git for developing them?
There is significant work remaining to get the CMakeVMMakerSqueak use documented, simplified (and some refactoring in plugins to be done). I would rather avoid that work (and move on to other projects) if the community can make better progress with straight CMake build scripts.
Let me know what your decision is.
cheers,
t
Hi David
Thank you for your reply. I will turn to different projects in the meantime.
cheers,
tty
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@freyther.de> wrote ----
> On 18 Jun 2016, at 23:28, commits@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
On 21 Jun 2016, at 02:02, gettimothy gettimothy@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/4ee7ca5666b74e0540ad75dd635...
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/216f47df008d0f73d24519bc302...
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
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/4ee7ca5666b74e0540ad75dd635...
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/216f47df008d0f73d24519bc302...
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
Hi Holger.
For the BSD, just take a generated CMake build tree for linux, copy it over to a BSD directory structure and hack away.
I will be happy to walk you through the steps.
When you get a working BSD Cmake thing going, I can store it in Smalltalk (If we decide to go that route)
Are you on a 64 bit machine or a 32 bit machine ?
Same for all you ARM and Dos guys.
cheers,
tty
---- On Mon, 20 Jun 2016 16:06:28 -0400 Holger Freyther<holger@freyther.de> wrote ----
> On 18 Jun 2016, at 23:28, commits@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
vm-dev@lists.squeakfoundation.org