Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.114.mcz
==================== Summary ====================
Name: CMakeVMMakerSqueak-tty.114 Author: tty Time: 26 February 2016, 11:17:09.37527 am UUID: 17dcb131-a2cc-4db4-94dd-e4e8b22ba90f Ancestors: CMakeVMMakerSqueak-tty.113
Modify New Configuration Step By Step to provide a conceptual overview in preparation for customizing the a new Configuration.
=============== Diff against CMakeVMMakerSqueak-tty.113 ===============
Item was changed: ----- Method: CMakeVMMakerSqueakConfigurationsHelp class>>overview (in category 'pages') ----- overview ^HelpTopic title:'Overview' contents: 'CMakeVMMakerSqueak Configurations. encapsulate CMake output.
To get a sense of what the CMake output file looks like, open a Transcript and evaluate the following:
Transcript clear. Transcript show: ((Linux64x86w32BitSqueakCogV3Config new) configureForBuildType: #build) contentForVmConfigCmake
+ The CMake encapsulation makes heavy us of CMakeTemplates--small wrapper classes that encapsulate CMake constructs; + It is the same idiom Seaside uses with its Components + - The CMake encapsulation is eased by storing CMakeTemplates--small wrapper classes that encapsulate CMake constructs. CMakeTemplate browseHierarchy.
Configurations Are organized by Platform in specific Class Categories. Example: CMakeVMMakerSqueak-MacOSPowerPC contains all the configurations for that platform.
Configurations should adhere to a naming convention that mirror Eliot Miranda''s Autotools build system layout: [Platform][Language][VM][Memory Model][Foo]Config.
Examples: Plan9NewspeakSistaSpurConfig MacOSXSqueakCogSpurConfig Windows32SqueakStackV2JoesPersonalTotallyAweseomeConfig
Configurations can support the available build types: #build, #buildDebug, #buildAssert...etc. Configurations can exclude themselves from being built. Configurations can exclude themselves from supporting particular build types.
+ For each buildType, a Configuration encapsulates the CMake configuration for that buildType.. - For each buildType, a Configuration encapsulates CMake configuration parameters for that buildType..
To use a Configuration, we tell it to configure itself for a particular build type and then generate its output.
'!
Item was changed: ----- Method: CMakeVMMakerSqueakConfigurationsHelp class>>pages (in category 'accessing') ----- pages + " #(overview CMakeVMMakerSqueakStepByStepNewConfigurationHelp CMakeVMMakerSqueakStepByStepNewPlatformHelp)" + ^#(overview CMakeVMMakerSqueakStepByStepNewConfigurationHelp) + ! - ^#(overview CMakeVMMakerSqueakStepByStepNewConfigurationHelp CMakeVMMakerSqueakStepByStepNewPlatformHelp)!
Item was changed: ----- Method: CMakeVMMakerSqueakDesignPatternsHelp class>>redirectPatternHeirarchy (in category 'pages') ----- redirectPatternHeirarchy ^HelpTopic title: 'Method Redirect Heirarchy' contents: + 'To get a sense of the hierarchy and this pattern browse - 'To get a sense of the hierarchy and this pattern browse the Abstract Base Class - Linux64x86w32BitConfig
+ ToolSet browseMessageCategory: ''cmake buildType redirects'' inClass:CPlatformConfigForSqueak + Under the ''cmake buildType redirects'' protocol we see coreSourcesBuld and coreSourcesBuilMultiThreaded.
Under coreSourcesBuild "files to include from src/vm dir" ^ #( ''cogit.c'' ''gcc3x-cointerp.c'' <--single threaded version )
We see single c files for a single-threaded interpreter, while under
coreSourcesBuildMultiThreaded "files to include from src/vm dir" ^ #( ''cogit.c'' ''cointerpmt.c'' <--multi threaded version )
We get the multi-threaded version.
Continuing down the heirarchy to Linux64x86w32BitSqueakCogV3Config we see the real power of this in its redirect methods:
Here we can set compiler flags, linker flags, libraries, and pre-processor flags that are customized for each build type.
To put this in terms of Eliot''s Autotools directory hierarchy these methods map directly to the .mvm files in his various build directories.
'!
Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>cPlatformConfigForSqueak (in category 'pages') ----- + cPlatformConfigForSqueak + "This method was automatically generated. Edit it using:" + "a HelpBrowser edit: #cPlatformConfigForSqueak" + ^HelpTopic + title: 'CPlatformConfigForSqueak' + contents: + 'CPlatformConfigForSqueak browse + + CPlatformConfForSqueak encapsulates data and methods/behaviors that span computer platforms. + + The immediate children of CPlatformConfigForSqueak + + SqueakMacintoshConfig + SqueakUnixConfig + SqueakWindowsConfig + + begin the specialization required for the Macintiosh , Unix and Windows machines. Adding a new platform, say VAX, is as easy as + CPlatformConfigForSqueak subclass:#SqueakVAXConfig and configure its relevant data/methods for that platform. + + An example of Configuration customization at the platform level is in the executableType method. + + SystemNavigation default browseMethodsWhoseNamesContain: ''executableType'' + + Here, we see that CPlatformConfForSqueak requires that a subclass implement it. The other subclasses may impliment it with an appropriate return value. + + Configurations are further refined as we proceed down the heirarchy. + + SqueakMacOSX32x86Config browseHierarchy + + Here we see a (stub) configuration for Mac OSX32 on the x86 processor. + + Our new Linux64x86w32BitSqueakCogSpurConfig configuration fits into its expected place under the Unix hierarchy. + + Linux64x86w32BitSqueakCogSpurConfig browseHierarchy + + The key and art of customizing our Linux64x86w32BitSqueakCogSpurConfig is to customize our Configuration at the appropriate level. + Higher levels should provide existing, appropriate configuration. Our job is to then implement and customize at the finest level of customization. + + To understand the how and why of customizing a Configuration, we turn to the heavily implemented design pattern I call the "Method Redirect Pattern". + + We cover that next. + + + + + + + + + + + + N.B. The ''Squeak'' prefix is unfortunate as it violates the naming convention. It is a holdover from initial attempts with the Pharo CMakeVMMaker code base. + I will attempt to remember to rename these after the Pharo dependency is removed. + + + + + + + + + + CPlatformConfigForSqueak is a child of CPlatformConfig, the root Configuration in Pharo''''s CMakeVMMaker. + + This is temporary as I have decided to de-couple CMakeVMMakerSqueak from CMakeVMMaker. + + + ToolSet browseMessageCategory:''cmake'' inClass: CPlatformConfigForSqueak!!' readStream nextChunkText!
Item was changed: ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>firstCMakeGeneration (in category 'pages') ----- firstCMakeGeneration + "This method was automatically generated. Edit it using:" + "a HelpBrowser edit: #firstCMakeGeneration" ^HelpTopic + title: 'First CMake Generation' + contents: - title:'First CMake Generation' - contents: 'For didactic purposes I am going to do a sanity check and generate CMake code from the configuration for the first time.
If you are not familiar with the CMakeVMMakerSqueak naming conventions, please evaluate: HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp
+ On my system a copy of the Cog svn tree is located under my current working Squeak directory in the folder ''oscogvm". - On my system the Cog svn tree is located under my Squeak install directory in the folder ''oscogvm".
+ It looks like this: - Opening an X-term and navigating there it looks like this:
+ bash-4.2$ ls --width=1 ~/usr/src/smalltalk/CMake.oscog/cogspurVMMaker/oscogvm/ - bash-4.2$ pwd - /home/tty/usr/src/smalltalk/CMake.oscog/cogVMMaker/oscogvm - - The contents of the directory look something like this. Note the subdirectory that starts with ""cmake."" - - bash-4.2$ ls --width=1 - CHANGES - LICENSE README - README.old build build.linux32ARM build.linux32x86 + build.linux64x64 build.macos32x86 build.macos64x64 build.win32x86 - cmake.build.linux64x86w32BitCompatibility <-----created by CMakeVMMakerSqueak for the Linux64x86w32BitSqueakCogV3Config history + mkNamedPrims.sh + nsspur64src + nsspursrc + nsspurstack64src + nsspurstacksrc + nssrc + platforms + processors + products + scripts + sources + spur64src + spursistasrc + spursrc + spurstack64src + spurstacksrc + src + stacksrc - image - .....
+ What I want to do is see if my configuration will write its output to an appropriate CMake subfolder. - That cmake.build.linux64x86w32BitCompatibility directory was generated by a previous cmake generation for the Linux64X86-32BitCompatibility Platform.
+ To do this, I ask the Builder to configure my new configuration for a buildType and output its contents. I do so by evaluating: - For demonstration sake, I remove the directory. - bash-4.2$ rm -Rf cmake.*
+ SqueakLinux64x86w32CompatBuilder + configureA: #Linux32x86SqueakCogSpurConfig forBuildType:#build; - Now, I ask the Builder to configure my new configuration for a buildType and output its contents. I do so by evaluating: - - SqueakLinux32x86Builder - configureA: #Linux32x86SqueakCogV3Config forBuildType:#build; enableMessageTracking: true; generateByTemplate.
- (Note: if you get errors during the generatation, shut down squeak and restart. I think it has something to do with open file handles):
and look again + bash-4.2$ ls --width=1 usr/src/smalltalk/CMake.oscog/cogspurVMMaker/oscogvm/ + CHANGES + LICENSE + README + build + build.linux32ARM + build.linux32x86 + build.linux64x64 + build.macos32x86 + build.macos64x64 + build.win32x86 + cmake.build.linux64x86w32BitCompatibility <--Here is the directory created by my configuration. + history + ....
+ Above we see that a new cmake.build.linux64x86w32BitCompatibility directory has been created. Let''s look at its contents - bash-4.2$ ls cmake.build.linux64x86w32BitCompatibility/ - squeak.cog.v3
+ tree -d ~/usr/src/smalltalk/CMake.oscog/cogspurVMMaker/oscogvm/cmake.build.linux64x86w32BitCompatibility/ + `-- squeak.cog.v3 <--We will be changing this later as we want a squeak.cog.spur directory, not a V3 directory + `-- build <--our build type is #build - bash-4.2$ tree cmake.build.linux64x86w32BitCompatibility/ - `-- squeak.cog.v3 - `-- build |-- ADPCMCodecPlugin - | `-- CMakeLists.txt - ...etc - We see that the configuration has generated its build heirarchy. - - Note, however that the cmake.build.linux64x86w32BitCompatibility directory is for a different Platform!! Since we copied an existing Configuration from a different platform, this make sense. - - To change it, we go to our Abstract Base Class and modify - - Linux32x86Config>>dirBuildPlatform - ^self dirLinux32x86 - - Then regenerate our CMake - - SqueakLinux32x86Builder - configureA: #Linux32x86SqueakCogV3Config forBuildType:#build; - enableMessageTracking: true; - generateByTemplate. - - And examine our directory: - - bash-4.2$ ls cmake.build.linux* - cmake.build.linux32x86: <dirLinux32X86 - squeak.cog.v3 - - and examining the heirarchy we see: - - bash-4.2$ tree -d cmake.build.linux32x86/ - cmake.build.linux32x86/ - `-- squeak.cog.v3 - `-- build - |-- ADPCMCodecPlugin |-- AsynchFilePlugin |-- B2DPlugin |-- BMPReadWriterPlugin |-- BitBltPlugin |-- CroquetPlugin |-- DSAPrims |-- DropPlugin |-- FFTPlugin |-- FileCopyPlugin |-- FilePlugin |-- FloatArrayPlugin |-- FloatMathPlugin |-- JoystickTabletPlugin |-- Klatt |-- LargeIntegers |-- LocalePlugin |-- MIDIPlugin |-- Matrix2x3Plugin |-- MiscPrimitivePlugin |-- Mpeg3Plugin |-- SecurityPlugin |-- SerialPlugin |-- SocketPlugin |-- SoundCodecPrims |-- SoundGenerationPlugin |-- SoundPlugin |-- StarSqueakPlugin |-- SurfacePlugin |-- ZipPlugin |-- vm-display-X11 |-- vm-display-null |-- vm-sound-ALSA + `-- vm-sound-null - `-- vm-sound-nul
+ ...etc + We see that the configuration has output a CMake build tree and we have done a sanity check.
+ Next we take stock of what we have accomplished and preview the remaining tasks. - Congratulations. You are almost done.
+ !!' readStream nextChunkText! - From here on out your only task is to correctly customize your Concrete Configuration such that it correctly builds for your [platform][language][vm][memorymodel][buildType] - - - - ' - - !
Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>methodRedirectPattern (in category 'pages') ----- + methodRedirectPattern + ^HelpTopic + title:'Review of Method Redirect Pattern' + contents: + 'The CPlatformConfigForSqueak provides methods that must be implemented at some level in the CPlatformConfigForSqueak hierarchy. + The design pattern is heavily used and you can get a sense of its scope by evaluating: + + ToolSet browseMessageCategory: ''cmake buildType redirects'' inClass:CPlatformConfigForSqueak + + The naming of the redirect methods follows a consistent pattern. + + fooBuild; + fooBuildAssert + fooBuildAssertITimerHeartbeat + fooBuildDebug + fooBuildDebugITimerHeartbeat + fooBuildITimerHeartbeat + fooBuildMultiThreaded + fooBuildMultiThreadedAssert + fooBuildMultiThreadedDebug + fooNoBuildType + + Where the suffix to ''foo'' denotes a specific buildType out of the available pool specified here: + + SqueakCMakeVMMakerAbstractBuilder allBuildTypes + + + The CPlatformConfigForSqueak either (rarely) implements or requires that at least one of these methods are implemented as such: + + fooBuild + self subclassResponsibility + + + At the same time, it does not require that all of them be implemented. It accomplishes this by defaulting to the ''fooBuild'' method: + + fooBuildAssertITimerHeartbeat + ^ self fooBuild + + You can see the ''foo'' pattern here in the ''cmakeAddDefinitions'' method + + SystemNavigation new browseAllImplementorsOf: #cmakeAddDefinitionsBuildMultiThreadedAssert localTo: CPlatformConfigForSqueak. + + Most buildTypes are redirected to a default implementation. This default implementation is implemented at an appropriate level in the CPlatformConfigHeirarchy + + There are some redirect methods that are appropriate to CPlatformConfigForSqueak; for example: + + SystemNavigation new browseAllImplementorsOf: #setGlobalOptionsBuild: localTo: CPlatformConfigForSqueak. + + Most methods are implemented lower in the hierarchy. + + When we implement a Configuration, we are implementing and or overriding methods in CMakePlatformConfigForSqueak that are appropriate for our buildType. + + The Method Redirect Pattern is covered in detail in an existing Help topic. + + HelpBrowser openOn: CMakeVMMakerSqueakDesignPatternsHelp + + Invocation of the Method Redirect Pattern occurs in the VMGenerator. We cover that next. + + ' + + !
Item was changed: ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>pages (in category 'accessing') ----- pages ^#(overview tests identifyPlatform identifyPlatformAbstractBaseClass identifyBuilder createTheConfiguration excludingConfigFromBuilds setAvailableBuildTypes firstCMakeGeneration + tackingStockOne + cPlatformConfigForSqueak + methodRedirectPattern - takingStock theVMGenerator + tackingStockTwo + setConfigurationDirectory + setOutputDirectory + settingPlugins + compilingLinkingSetup + customizeVMDrivers + customizePlugins + aNoteOnFoo + ) + + " ^#(overview + tests + identifyPlatform + identifyPlatformAbstractBaseClass + identifyBuilder + createTheConfiguration + excludingConfigFromBuilds + setAvailableBuildTypes + firstCMakeGeneration + theVMGenerator reviewMethodRedirectPattern setOutputDirectory settingPlugins compilingLinkingSetup customizeVMDrivers customizePlugins aNoteOnFoo + )"! - )!
Item was removed: - ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>reviewMethodRedirectPattern (in category 'pages') ----- - reviewMethodRedirectPattern - ^HelpTopic - title:'Review of Method Redirect Pattern' - contents: - 'Besides the VMGenerator>>generateByTemplate, the system relies heavily on what I call a Method Redirect Pattern. - - If you have not read it yet, its a short read here: - - HelpBrowser openOn: CMakeVMMakerSqueakDesignPatternsHelp - - ' - - !
Item was changed: ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>setAvailableBuildTypes (in category 'pages') ----- setAvailableBuildTypes ^HelpTopic title:'Setting Available Build Types' contents: 'Configurations inform Builders what BuildTypes they support. via the availableBuildTypes method
Here is my Builder asking my new Configuration what build types it supports (remember, this Configuration was copied, so it has been configured already)
SqueakLinux64x86w32CompatBuilder availableBuildTypesFor: #Linux64x86w32BitSqueakCogSpurConfig --> an OrderedCollection(#build #buildAssert)
+ In our Abstract Base Class (Which, you recall cannot be built )for our Platform, we default to no build types. - In our Abstract Base Class (Which, you recall cannot be buil)for our Platform, we default to no build types.
Linux64x86w32BitConfigUsrLib>>availableBuildTypes ^SqueakCMakeVMMakerAbstractBuilder default noBuildTypes
To get an idea of what buildTypes are available system wide evaluate SqueakCMakeVMMakerAbstractBuilder default allBuildTypes -->an OrderedCollection(#build #buildAssert #buildAssertITimerHeartbeat #buildDebug #buildDebugITimerHeartbeat #buildITimerHeartbeat #buildMultiThreaded #buildMultiThreadedAssert #buildMultiThreadedDebug #buildNone)
To set the available build types for a Concrete Configurations we override the AbstactBaseClass''s method and SUBTRACT OUT what we do not want. Like so:
Since I am starting simple, I want my configuration to build a vanilla build. To do this I remove all but #build buildType like so
Linux64x86w32BitSqueakCogSpurConfig >> availableBuildTypes ^SqueakCMakeVMMakerAbstractBuilder default allBuildTypes copyWithoutAll: #( #buildAssert #buildAssertITimerHeartbeat #buildDebug #buildDebugITimerHeartbeat #buildITimerHeartbeat #buildMultiThreaded #buildMultiThreadedAssert #buildMultiThreadedDebug #buildNone)
As I code more build types in my configuration, I subtract out
Linux32x86SqueakCogV3Config >> availableBuildTypes ^SqueakCMakeVMMakerAbstractBuilder default allBuildTypes copyWithoutAll: #( #buildMultiThreadedDebug #buildNone)
With the result that my Builder shows the removed items as Available Build Types:
SqueakLinux32x86Builder availableBuildTypesFor: #Linux32x86SqueakCogV3Config --> an OrderedCollection(#build #buildAssert #buildAssertITimerHeartbeat #buildDebug #buildDebugITimerHeartbeat #buildITimerHeartbeat #buildMultiThreaded #buildMultiThreadedAssert)
Since I will only be developing the #build buildType for now, I put it as so:
Linux32x86SqueakCogV3Config>>availableBuildTypes ^SqueakCMakeVMMakerAbstractBuilder default allBuildTypes copyWithoutAll: #( #buildAssert #buildAssertITimerHeartbeat #buildDebug #buildDebugITimerHeartbeat #buildITimerHeartbeat #buildMultiThreaded #buildMultiThreadedAssert #buildMultiThreadedDebug #buildNone)
and verify it is correct:
SqueakLinux32x86Builder availableBuildTypesFor: #Linux32x86SqueakCogV3Config -->an OrderedCollection(#build)
+ *N.B. tty. In my opinion, this is a weak design on my part. as it relies on the developer to set it up. If there is an elegant way to do this , I am for it. - *N.B. tty. In my opinion, this is a weak design on my part. as it relies on the developr to set it up. If there is an elegant way to do this , I am for it. '!
Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>setConfigurationDirectory (in category 'pages') ----- + setConfigurationDirectory + ^HelpTopic + title:'Set Configuration Directory' + contents: + ' + Need the squeak.cog.spur directory here. + + + '!
Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>tackingStockOne (in category 'pages') ----- + tackingStockOne + ^HelpTopic + title:'Taking Stock' + contents: + 'Let''s take stock of where we are. + + At this point, we have + 1. Created a Configuration for a specific platform, language, VM and memory model . + 2. Invoked the appropriate Builder for that Configuration asking it to ... + 2.a configure itself for a specific BuildType and + 2.b asked it to ouput its content to a specific directory. + 3. Confirmed that the Configuration outputs its data. + + The remainder of our task is customizing our Configuration so that the generated data correctly builds as the intention revealing name of the Configuration implies. I.e. we expect a Linux64x86w32BitSqueakCogSpurConfig, when configured for the buildType #build to generate CMake (and other) files that in fact, creates a release version of a squeak.cog.spur vm that runs on Linux64 with 32 bit compat libs stored in /usr/lib. + + Before we dive into customizing our new Configuration, we step back to gain some perspective so that if there are problems, you know where to look. + + We will start by a quick summary of.. + + 1. The root Configuration class CPlatformConfigForSqueak + 2. The ''method redirect'' design pattern. + 3. The CMakeVMGeneratorForSqueak class + + + After that, we will take stock again and proceed with the customization of our example Linux64x86w32BitSqueakCogSpurConfig + '!
Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>tackingStockTwo (in category 'pages') ----- + tackingStockTwo + ^HelpTopic + title:'Taking Stock II' + contents: + 'To recap, at this point, we have + 1. Created a Configuration for a specific platform, language, VM and memory model . + 2. Invoked the appropriate Builder for that Configuration asking it to ... + 2.a configure itself for a specific BuildType and + 2.b asked it to ouput its content to a specific directory. + 3. Confirmed that the Configuration outputs its data. + + We know that + + Configuration is performed at the highest appropriate Configuration with fine-tuning at the lower Configuration levels. + The Method Redirect Pattern is implemented in CPlatformConfigForSqueak. It is boilerplate code. + A specific Configuration may override a Method Redirect method for a particular build type to provide custom output + The CMakeVMGeneratorForSqueak takes our Configuration as input via the Visitor pattern and executes the Method Redirect methods in a predictable way based on the Configurations buidType.. + + + The remainder of this Example Workflow will be the customization of the Linux64x86w32BitSqueakCogSpurConfig and generating a working build. + + '!
Item was removed: - ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>takingStock (in category 'pages') ----- - takingStock - ^HelpTopic - title:'Where You Are Now' - contents: - ' If your Concrete Builder has successfully generate the CMake tree in the correct folder structure then you are almost done. - - The rest of the process from here on out is tweaking the Concrete Configuration so that it generates valid CMake for your platform and buildTypes. - - If you have not generated CMake output at this point, go back and try until you can. - - At this point, please evaluate: - HelpBrowser openOn: CMakeVMMakerSqueakDesignPatternsHelp - - And read the section on the Method Redirect Pattern before continuing. - ' - - !
Item was changed: ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>theVMGenerator (in category 'pages') ----- theVMGenerator ^HelpTopic + title:'The CMakeVMGeneratorForSqueak class' - title:'The VM Generator' contents: + 'Before we move onto setting the most common directives and flags in the Concrete Configuration, lets take a quick look at the class and method that actually generates the CMake files for us. - 'Before we move onto setting the most common directives and flags in the Concrete Configuration, lets take a quick look at the method that actually generates the CMake files for us. You probably will not need this, but its handy to know of.
+ CMakeVMGeneratorForSqueak browseHierarchy - CMakeVMGeneratorForSqueak browse
- Look at the generateByTemplate method and the long cascade that starts with:
+ CMakeVMGeneratorForSqueak implements the Visitor Design pattern. It takes as input a Configuration and it operates on that Configuration in a methodical manner. + + The CMakeVMGeneratorForSqueak has in instance variable named ''config''. This variable is our Configuration. + + The methodical operation on the Configuration occur in its generateByTemplate method. + + To see this, look at the generateByTemplate method and the long cascade that starts with: + config setGlobalOptions: self; cmakePrefixPath; cmakeIncludePath;.....
+ Here you see the generator iterating over the CPlatformConfigForSqueak Method Redirect methods. - Here you see the generator extracting CMake data from your Configuration in a straighforward order.
+ SystemNavigation new browseAllImplementorsOf: #cmakeIncludePath localTo: CPlatformConfigForSqueak. - The names of the methods are a bit of a holdover from the pharo code and do not conceptually match the sections of Ian Piumarta''s CMake template.
+ Here you see that based on the Configurations buildType, the appropriate Redirect Method out of + cmakeIncludePathBuild + cmakeIncludePathBuildAssert + cmakeIncludePathBuildAssertITimerHeartbeat + cmakeIncludePathBuildDebug + cmakeIncludePathBuildDebugITimerHeartbeat + cmakeIncludePathBuildITimerHeartbeat + cmakeIncludePathBuildMultiThreaded + cmakeIncludePathBuildMultiThreadedAssert + cmakeIncludePathBuildMultiThreadedDebug + cmakeIncludePathNoBuildType - If you generate your CMake files with message tracking enabled as per below
+ is executed. - SqueakLinux32x86Builder - configureA: #Linux32x86SqueakCogV3Config forBuildType:#build; - enableMessageTracking: true; <---message tracking - generateByTemplate.
+ For debugging and troubleshooting you new Configuration, CMakeVMGeneratorForSqueak>>generateByTemplate enables you to step through CMake generation in an entirely predictable way. - You can see in your CMakeLists.txt which method is responsible for which bits of code.
+ Let''s recap next. - Here we see these two lines from the VMGenerator - - config - .... - cmakeIncludeDirectories: self; - preferredIncludes; - .... - - tracked in the CMakeLists.txt - - message( "Linux32x86SqueakCogV3Config includeDirs: aMaker") <---message tracking message - include_directories( ${crossDir}/vm ${srcVMDir} ${targetPlatform}/vm ${buildDir}) <--output of cmakeIncludeDirectories:self - message( "Linux32x86SqueakCogV3Config preferredIncludesBuild") <--message tracking message - include_directories( ${targetPlatform}/plugins/B3DAcceleratorPlugin) <-- output of preferredIncludesBuild - '
!
Item was changed: ----- Method: CPlatformConfigForSqueak>>cmakeAddDefinitions (in category 'cmake buildType redirects') ----- cmakeAddDefinitions "Route this message send to the message appropriate for my buildType " |d | d:= SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo copy. d at: #build put: [self cmakeAddDefinitionsBuild]; at: #buildAssert put: [self cmakeAddDefinitionsBuildAssert]; at: #buildAssertITimerHeartbeat put: [self cmakeAddDefinitionsBuildAssertITimerHeartbeat]; + at:#buildDebug put: [self cmakeAddDefinitionsBuildDebug]; - at:#buildDebug put: [self cmakeAddDefinitionsPathBuildDebug]; at: #buildDebugITimerHeartbeat put: [self cmakeAddDefinitionsBuildDebugITimerHeartbeat ]; at: #buildITimerHeartbeat put: [self cmakeAddDefinitionsBuildITimerHeartbeat]; at: #buildMultiThreaded put: [self cmakeAddDefinitionsBuildMultiThreaded]; at: #buildMultiThreadedAssert put: [self cmakeAddDefinitionsBuildMultiThreadedAssert]; at: #buildMultiThreadedDebug put: [self cmakeAddDefinitionsBuildMultiThreadedDebug ]; at: #buildNone put:[self cmakeAddDefinitionsNoBuildType]. ^(d at: buildType) value!