[Vm-dev] tty's hypothesis on configH in CMakeVMMaker

gettimothy gettimothy at zoho.com
Tue Jun 17 02:49:57 UTC 2014


Hi All,


Just interjecting a couple of observations that might ease concerns.


First, thanks for the heads up on the "nm" command. I have it copied in my notes for when I return to debugging dynamically linked plugins.


Second, I think the CMakeVMakerSqueak will be easier to maintain than the GNU system and will provide better coverage. I have a long-winded explantion below if you are interested.


cheers.


tty






1. What I am seeing is two different build expectations. 


      Pharo is set up to build on a server to support pharo releases. For this job, CMakeVMMaker fits the build as the machine is a known quantity (?)
      
      Squeak (will be) set up to support a build on an initial set of [OS][VMWordSize][Processor]/[Language][VM][MemoryManager] 


2. Cog SVN build tree defines [OS][VMWordSize][Processor] directories for 
      build.linux32x86
      build.macos32x86
      build.win32x86
      bochs?

     each of must support 12 [Language][VM][MemoryManager] configurations. 
newspeak.cog.spur
newspeak.cog.v3
newspeak.sista.spur
newspeak.sista.v3
newspeak.stack.spur
newspeak.stack.v3
squeak.cog.spur
squeak.cog.v3
squeak.sista.spur
squeak.sista.v3
squeak.stack.spur
squeak.stack.V3


each of which must support buildTypes of: build build.assert build.assert.itimerheartbeat build.debug build.debug.itimerheartbeat build.itimerheartbeat build.multithreaded build.multithreaded.assert build.multithreaded.debug


These MUST dynamically configure themselves for the GNU Builds.


However, in CMake these directories are coupled with Configuration Classes named after each combination of the above: [OS][VMWordSize][Processor][Language][VM][MemoryManager].


This gives us a base-line configuration that can be extended for edge cases. Each [OS][VMWordSize][Processor][Language][VM][MemoryManager] also dynamically configures itself for  the different buildTypes, so in essence you have
[OS][VMWordSize][Processor][Language][VM][MemoryManager][buildType] baseline configs


Eliot is correct that this is not flexible as "Linux/Unix" specifies a lot if flavors of "Unix" as we see with the 3 possibilities of uuid.h in just one plugin for that platform. So....


3. We can stretch things a bit in  CmakeVMaker(Squeak) we can extend this by creating additional [OS][VMWordSize][Processor] directories for "unix" platforms like this
      BSD32x86
      SunOS32x?? 
      Linux32ARMv6
      Linux64X86-32BitCompatibility
 
      So that "could" take care of the config.h specification for that platform.


      Edge cases for a [OS][VMWordSize][Processor][Language][VM][MemoryManager] standard configuration are made by subclassing the standard
            I (will be by tomorrow when I refactor the thing) am encapsulating the configuration for Linux64x86w32BitSqueakCogV3 in a subclass named Linux64x86w32BitSqueakCogV3SlackwareNoGL
            CMakeVMaker has Debian configs that I will be rolling into the mix soon
      
4. Once release 1 of this  puppy, we can evaluate pursing using CMake to generate config.h. I don't know how to at the moment, but a quick search leads me to believe it can be done:
     http://stackoverflow.com/questions/9639449/cmake-how-to-pass-preprocessor-macros
 













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


More information about the Vm-dev mailing list