Vm-dev May 2016

vm-dev@lists.squeakfoundation.org

36 participants
150 discussions

VM Maker: CMakeVMMakerSqueak-tty.115.mcz
by commits＠source.squeak.org 29 May '16

29 May '16

Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.115.mcz ==================== Summary ==================== Name: CMakeVMMakerSqueak-tty.115 Author: tty Time: 1 April 2016, 6:25:28.843934 pm UUID: 689607f1-9482-4e6c-b342-ada9c1108511 Ancestors: CMakeVMMakerSqueak-tty.114 incremental save. Continued work on documenting how to create a new configuration while I actually create one. The documentation is taking much longer than the actual work. (: =============== Diff against CMakeVMMakerSqueak-tty.114 =============== Item was changed: ----- Method: CMakeVMGeneratorForSqueak>>generateByTemplate (in category 'code generation') ----- generateByTemplate "attempt to move way from string based writing to template based. Think Seaside renderOn composition" | extPlugins intPlugins | self flag: 'tty'. "refactor so that the cascade reflects CMake terminilogy" output := String new writeStream. config templates: OrderedCollection new. + self break. config setGlobalOptions: self; cmakePrefixPath; cmakeIncludePath; cmakeLibraryPath; cmakeIncludeModules; cmakeCFlags; cmakeAddDefinitions; cmakeWriteDirectoriesDotCmake: self; cmakeIncludeDirectories: self; "<---" preferredIncludes; "<---why 3 of em?" standardIncludes; "<---" setGlobalOptionsAfterDetermineSystem: self; extraVMSettings: self; "<--catch-all method. os/platform specific" - break; setCoreSources: self; setPlatformSources: self; setCrossSources: self; setExtraSources; cmakeSetSourceFilesProperties; cmakeListAppend:'LINKLIBS' elements: (config externalLibs); cmakeAddExecutableNameOptionSource: self; setExecutableOutputPath; addVMPlugins: self. config templates do: [:each | self puts: each content]. config templates: OrderedCollection new. extPlugins := self generatePluginConfigs: config internalPlugins internal: true. intPlugins := self generatePluginConfigs: config externalPlugins internal: false. self processThirdpartyLibraries. "<--unused in Pharo code? What exactly does this do?" self processPlugins: intPlugins, extPlugins. self config templates addLast:((CMakeCommand new) command:'target_link_libraries' params:(self moduleName , ' ${LINKLIBS}')). " self cmd: 'target_link_libraries' params: self moduleName , ' ${LINKLIBS}'." config postBuildActions: self.. config templates do: [:each | self puts: each content]. self saveFile. self generateBuildScript! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>addVMPlugins (in category 'pages') ----- + addVMPlugins + ^HelpTopic + title:'addVMPlugins' + contents: + ' + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>cmakeAddDefinitions (in category 'pages') ----- + cmakeAddDefinitions + ^HelpTopic + title:'cmakeAddDefinitions' + contents: + 'SystemNavigation browseAllImplementorsOf: #cmakeAddDefinitions + + We see that the CPlatformConfigForSqueak routes the method based on the buildType #build via the Method Redirect pattern to cmakeAddDefinitionsBuild + + SystemNavigation browseAllImplementorsOf: #cmakeAddDefinitionsBuild + + We see that our Linux64x86w32BitSqueakCogSpurConfig already implements it due to our copying of an existing configuration. + + We need to modify this for our Configuration. The current method (minus commented out elements) reads as: + + definitions:=#( + ''-DNDEBUG'' + ''-DDEBUGVM=0'' + '' -DLSB_FIRST=1'' + ''-D_GNU_SOURCE'' + ''-D_FILE_OFFSET_BITS=64'' + ''-DCOGMTVM=0'') . + + Like the cmakeCFlags method, we look at the mvm file + + cat ~/.../Cog/build.linux32x86/squeak.cog.spur/build/mvm + + And see the + 3.4.*) OPT=''-g -O1 -fwrapv -DNDEBUG -DDEBUGVM=o'';; + *) OPT=''-g -O2 -DNDEBUG -DDEBUGVM=0'';; + + lines and the + + CFLAGS=''$OPT -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DCOGMTVM=0'' \ + + Based on these mvm file details, I modify the method to read as such: + + definitions:=#( + ''-DNDEBUG'' + ''-DDEBUGVM=0'' + ''-D_GNU_SOURCE'' + ''-D_FILE_OFFSET_BITS=64'' + ''-DCOGMTVM=0'') . + + To match the directives specified in the mvm file + + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>cmakeAddExecutableNameOptionSource (in category 'pages') ----- + cmakeAddExecutableNameOptionSource + ^HelpTopic + title:'cmakeAddExecutableNameOptionSource:' + contents: + 'SystemNavigation browseAllImplementorsOf: #cmakeAddExecutableNameOptionSource: + + We see this is a top-level method implemented only by CPlatformConfigForSqueak + + The method creates a new CMakeAddExecutableNameOptionSource template + + CMakeAddExecutableNameOptionSource browse + + and the class comment says it "Add an executable to the project using the specified source files." + + To get a sense of the CMake output print the following: + + ((CMakeAddExecutableNameOptionSource new) + executableName: ''cog'' + optionalproperty: '''' + sources: (OrderedCollection with: ''${coreSources} ${crossVMSources} ${platformVMSources} ${extraSources}'')) content + + In looking at this, the exectuableName worries me. I am not sure that ''cog'' is what we want. + + Looking at it... + SystemNavigation browseAllImplementorsOf: #executableName + + it is something we can customize or code if we need. + + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>cmakeCFlags (in category 'pages') ----- + cmakeCFlags + ^HelpTopic + title:'cmakeCFlags' + contents: + 'SystemNavigation browseAllImplementorsOf: #cmakeCFlags + + We see that CPlatformConfigForSqueak implements it + + The method comment reads in part: + + ''self deprecated: this catchall method has been split into dedicated methods: cmakePrefixPath cmakeIncludePath cmakeLibraryPath cmakeIncludeModules; cmakeCFlags; ...'' + + + And that this method will be refactored out of existence ''soon''. + + Looking at it, we see that the method implements the Method Redirect pattern + + Since we have configured for buildType: #build, the Method Redirect Pattern will invoke the cmakeCFlagsBuild method. + + So we look at the implementors of it.. + + SystemNavigation browseAllImplementorsOf: #cmakeCFlagsBuild + + Here we see that our new Linux64x86w32BitSqueakCogSpurConfig configuration implements it (since we copied an existing Configuration that implemented it) + + We now have something to customize. + + We look at the line: cflags:= String streamContents: [:stream | (self compilerFlags) asStringOn: stream delimiter: '' '' ]. + + and see that our ''self compilerFlags'' method is used. + + SystemNavigation browseAllImplementorsOf: #compilerFlags + + These are flags to pass to the compiler. Take a look at the mwm file in the GNU config + + cat ~/.../Cog/build.linux32x86/squeak.cog.spur/build/mvm + + We see an OPT variable being populated... + + + OPT=''-g -O1 -fwrapv -DNDEBUG -DDEBUGVM=0'';; + OPT=''-g -O2 -DNDEBUG -DDEBUGVM=0'';; + esac + + And later in the file we see the CFLAGS variable being populated with the $OPT variable and some other flags. + + CC=''gcc -m32'' \ + CXX=''g++ -m32'' \ + CFLAGS=''$OPT -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DCOGMTVM=0'' \ + LIBS=''-lpthread -luuid'' \ + LDFLAGS=-Wl,-z,now + + That CFLAGS variable is what we are mimicing here. with some caveats... + + The pharo code just dumped all that stuff into one method, whereas I split them up. + + We are ommitting the Compiler defines like -D_GNU_SOURCE as we will be setting those in cmakeAddDefinitions. + + My current compilerFlags (minus commented out elements) method reads like this: + + compilerFlags + ^#( ''-w'' + ''-m32'' + ''-msse2'' + ''-O1'') + + + checking my compiler version + bash-4.2$ gcc --version + gcc (GCC) 4.8.2 + Copyright (C) 2013 Free Software Foundation, Inc. + This is free software; see the source for copying conditions. There is NO + warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + I see I need some options from the OPT=''-g -O1 -fwrapv -DNDEBUG -DDEBUGVM=0'' line + line + + + Mimicing the mvm file, I modify it to read as such: + + compilerFlags + ^#(''-g'' + ''-O1'' + ''-fwrapv'' + ''-m32'' + ''-msse2'' + ) + + In doing this, I am congizant that I may have to return to this method as I fiddle around getting this configuration correct. + + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>cmakeIncludeDirectories (in category 'pages') ----- + cmakeIncludeDirectories + ^HelpTopic + title:'cmakeIncludeDirectories' + contents: + 'SystemNavigation browseAllImplementorsOf: #cmakeIncludeDirectories: + + We see that the sole implementor of the method is the top level configuration CPlatformConfigForSqueak + + The method creates an instance of the CMakeTemplate CMakeIncludeDirectories + + CMakeIncludeDirectories browse + + where the class comment tells us that it tells CMake to add extra ''include'' directories to the build. + + Currently a variable placeholder is hard-coded in CMakeVMGeneratorForSqueak>>includeDirs + You can print the following to see them: + (CMakeVMGeneratorForSqueak new) includeDirs + + And the generated CMake by printing the following: + + ((CMakeIncludeDirectories new) dirs: (OrderedCollection with: (CMakeVMGeneratorForSqueak new) includeDirs)) content + + What you see when you print it are variable placeholders that CMake will populate with the value of CMake variables ${crossDir} + , ${srcVMDir} and ${targetPlatform} that we will be defining or have already been defined in our configuration. + + This is truly a global method and would only change if Eliot changed the layout of the underlying build structure. + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>cmakeIncludeModules (in category 'pages') ----- + cmakeIncludeModules + ^HelpTopic + title:'cmakeIncludeModules' + contents: + 'CMake allows the user to include custom CMake library files (modules). + This construct allows the developer to include those modules. + + cmakeIncludeModules implements the Method Redirect pattern. + + ToolSet browse: CPlatformConfigForSqueak selector: #cmakeIncludeModules + + Since the configuration is configured for buildType: #build the method redirect pattern will redirect to + + SystemNavigation browseAllImplementorsOf: #cmakeIncludeModulesBuild. + + We see in CPlatformConfigForSqueak that a sublcass must implement it via ''self subclassResponsibility''. + + We see that (as of this writing) the SqueakUnixConfig handles the method by including some custom modules + Utils.cmake + Plugins.cmake + TestBigEndian + CheckIncludeFile + CheckLibraryExists + CheckTypeSize + CheckFunctionExists + CheckVariableExists + CheckStructHasMember + FindPkgConfig + + These Module wrap CMake constructs and can be thought of as CMake ''include files''. and they are implemented high in the Configuration platform hierarchy. + + Our new Configuration need not override anything here. + + Let''s move on...'! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>cmakeIncludePath (in category 'pages') ----- + cmakeIncludePath + ^HelpTopic + title:'cmakeIncludePath' + contents: + 'cmakeIncludePath implements the Method Redirect pattern. + + ToolSet browse: CPlatformConfigForSqueak selector: #cmakeIncludePath + + Since the configuration is configured for buildType: #build the method redirect pattern will redirect to + + SystemNavigation browseAllImplementorsOf: #cmakeIncludePathBuild + + We see in CPlatformConfigForSqueak that a sublcass must implement it via ''self subclassResponsibility''. + + We see that (as of this writing) the SqueakUnixConfig handles the method, but only for debug messages. + + There is a possibility a sub-platform will have include files in a non-standard directories and a specific Configuration + will have to implement this to generate appropriate CMake output. + + At this moment, we conclude we don''t need to. + + Since I am writing this help in tandem with generating a new Configuration, there is the possibility I am wrong and that I will need this. + + Since I don''t know for a fact that it is, I leave it alone for now.'! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>cmakeLibraryPath (in category 'pages') ----- + cmakeLibraryPath + ^HelpTopic + title:'cmakeLibraryPath' + contents: + 'cmakeLibraryPath implements the Method Redirect pattern. + + ToolSet browse: CPlatformConfigForSqueak selector: #cmakeLibraryPath + + Since the configuration is configured for buildType: #build the method redirect pattern will redirect to + + SystemNavigation browseAllImplementorsOf: #cmakeLibraryPathBuild. + + We see in CPlatformConfigForSqueak that a sublcass must implement it via ''self subclassResponsibility''. + + We see that (as of this writing) the SqueakUnixConfig handles the method, but only for debug messages. + + There is a possibility a sub-platform will have libraries in a non-standard directories and a specific Configuration + will have to implement this to generate appropriate CMake output. + + At this moment, we conclude we don''t need to. + + Since I am writing this help in tandem with generating a new Configuration, there is the possibility I am wrong and that I will need this. + + Since I don''t know for a fact that it is, I leave it alone for now. + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>cmakeListAppend: (in category 'pages') ----- + cmakeListAppend:LINKLIBSelements + ^HelpTopic + title:'cmakeListAppend:LINKLIBSelements' + contents: + ' + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>cmakeListAppendLINKLIBSelements (in category 'pages') ----- + cmakeListAppendLINKLIBSelements + ^HelpTopic + title:'cmakeListAppendLINKLIBSelements' + contents: + 'SystemNavigation browseAllImplementorsOf: #cmakeListAppend:elements: + + We see this is a top-level method. + + The method creates a new CMakeListAppend which according to the class comment ''I handle the APPEND functionality for the cmake list commmand.''. + + Here we are appending libraries to link to the list LINKLIBS. + + You can get a sense of the CMake output by evaluating. + + ((CMakeListAppend new) list:''LINKLIBS'' elements:#((''-L/usr/lib'' ''-L/usr/lib/X11'' ''uuid'' ''ssl'' ''crypto'' ''m'' ''dl'' ''pthread'' ''SM'' ''ICE'' ''GL'' ''X11'' ''nsl''))) content + + The list of libraries is available via the configurations ''externalLibs'' method. + + SystemNavigation browseAllImplementorsOf: #externalLibs + + Which we see implements the Method Redirect pattern. + + Since this is a #build buildType we look in + + SystemNavigation browseAllImplementorsOf: #externalLibsBuild + + And we see the CPlatformConfigForSqueak subclasses responsibility and that our new Linux64x86w32BitSqueakCogSpurConfig implements it as + + externalLibsBuild + ^self externalLibraries asOrderedCollection. + + which is contained in its parent as + + externalLibraries + ^#( + ''-L/usr/lib'' + ''-L/usr/lib/X11'' + ...... + etc... + ) + + + So, we see the ability to specify what libraries we want to link against in our configuration. + + Where to do this in the Configuration heirarchy is a matter of judgement. + + We will leave this one alone, bearing in mind that if we have a library linking problem, we have an idea where to look for it. + + + + + + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>cmakePrefixPath (in category 'pages') ----- + cmakePrefixPath + ^HelpTopic + title:'cmakePrefixPath' + contents: + 'ToolSet browse: CPlatformConfigForSqueak selector: #cmakePrefixPath + + cmakePrefixPath implements the Method Redirect pattern. + + Since the configuration is configured for buildType: #build the method redirect pattern will redirect to + + SystemNavigation browseAllImplementorsOf: #cmakePrefixPathBuild + + We see in CPlatformConfigForSqueak that a sublcass must implement it via ''self subclassResponsibility''. + + We see that (as of this writing) the SqueakUnixConfig handles the method. + + We reason that this method generates platform specific CMake output and our lower-level Configuration need not override it. + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>cmakeSetSourceFilesProperties (in category 'pages') ----- + cmakeSetSourceFilesProperties + ^HelpTopic + title:'cmakeSetSourceFilesProperties' + contents: + 'SystemNavigation browseAllImplementorsOf: #cmakeSetSourceFilesProperties + + SystemNavigation browseAllImplementorsOf: #cmakeSetSourceFilesPropertiesBuild + + We see that the CPlatformConfigForSqueak subclasses responsibility (scroll down past the method comment) + + We also see that our new Linux64x86w32BitSqueakCogSpurConfig Configuration implements it. + + I suspect this method will be refactored upwards. It appears to be passing distinct compiler flags to the cogit.c and sqUnixHeartbeat.c. + + + Let''s leave this one alone. + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>cmakeWriteDirectoriesDotCmake (in category 'pages') ----- + cmakeWriteDirectoriesDotCmake + ^HelpTopic + title:'cmakeWriteDirectoriesDotCmake' + contents: + 'SystemNavigation browseAllImplementorsOf: #cmakeWriteDirectoriesDotCmake: + + Here we see that the CPlatformConfigForSqueak forces subclasses to implement this . + + This method sets some CMake variables to platform specific values and writes them to a file named ''directories.cmake'' + + Here is the directories.cmake file contents on my platform + + bash-4.2$ cat directories.cmake + set(topDir "/home/tty/usr/src/smalltalk/CMake.oscog/cogspurVMMaker/oscogvm") + set(buildDir "/home/tty/usr/src/smalltalk/CMake.oscog/cogspurVMMaker/oscogvm/cmake.build.linux64x86w32BitCompatibility/squeak.cog.v3/build") + set(thirdpartyDir "${buildDir}/thirdParty") + set(platformsDir "/home/tty/usr/src/smalltalk/CMake.oscog/cogspurVMMaker/oscogvm/platforms") + set(srcDir "/home/tty/usr/src/smalltalk/CMake.oscog/cogspurVMMaker/oscogvm/src") + set(srcPluginsDir "${srcDir}/plugins") + set(srcVMDir "${srcDir}/vm") + set(platformName "unix") + set(targetPlatform "${platformsDir}/${platformName}") + set(crossDir "${platformsDir}/Cross") + set(platformVMDir "${targetPlatform}/vm}") + set(outputDir "/home/tty/usr/src/smalltalk/CMake.oscog/cogspurVMMaker/oscogvm/cmake.products/squeak.cog.v3") + set(externalModulesDir "${outputDir}") + + EOF + + The file contains CMake ''set'' commands that bind a variable to a value. + + In this application, CMake commands are encapsulated as objects and the CMake Set command is no exception: + + CMakeSet browse + + Taking the set(platformName,"unix") command as an example, we see the rationale for sublcassing this construct to the platform specific subclasses. + + + There is nothing for us to do here, HOWEVER, we will be customizing some variables that compose this. For example: + set(srcDir "some path to a source directory") can take any of the below directory names: + + nsspur64src + nsspursrc + nsspurstack64src + nsspurstacksrc + nssrc + spur64src + spursistasrc + spursrc + spurstack64src + spurstacksrc + src + stacksrc + + + + + + + + + + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>extraVMSettings (in category 'pages') ----- + extraVMSettings + ^HelpTopic + title:'extraVMSettings' + contents: + 'SystemNavigation browseAllImplementorsOf: #extraVMSettings: + + + In the CPlatformConfigForSqueak>>extraVMSettings: aMaker, we see the Method Redirect Pattern employed. Since this is for buildType #build, the method will re-route to self extraVMSettingsBuild: + + SystemNavigation browseAllImplementorsOf: #extraVMSettingsBuild: + + We see the CPLatformConfigForSqueak forces a subclass to implement it and the SqueakUnixConfig implements it. + + In SqueakUnixConfig a CMakeAddCustomCommandOutput is created and initialized. + + CMakeAddCustomCommandOutput browse + + The class comment says that: ''Add a custom build rule to the generated build system.'' + + + If you look in the file Cog/platforms/unix/config/verstamp you see that this is (looks like) the definition/implemenation of the command CMake + will invoke. + + + Currently this is a platform level method. Honestly, I have no idea why it is there. (: + + For our purposes, there is nothing we need to do. + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>forTheImpatient (in category 'pages') ----- + forTheImpatient + ^HelpTopic + title:'For the impatient' + contents: + 'Here is the TL;DR synopsis of the methods I implemented or overrode in creating the Linux64x86w32BitSqueakCogSpurConfig. + For a step-by-step exposition please continue to the next page. + + TODO: Fill this in as you go + cmakeCFlags + cmakeAddDefinitions + + + '! Item was changed: ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>overview (in category 'pages') ----- overview ^HelpTopic title:'Overview' contents: 'This Help Topic presents the workflow the author used in creating the Squeak, Cog, Spur CMake configuration for a 64 bit Slackware 14.1 system.with 32 bit compatability libs in /usr/lib + Although some details will be different, the steps involved should be the same for any platform.'! - The steps involved should be the same for any platform.'! Item was changed: ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>pages (in category 'accessing') ----- pages ^#(overview tests identifyPlatform identifyPlatformAbstractBaseClass identifyBuilder createTheConfiguration excludingConfigFromBuilds setAvailableBuildTypes firstCMakeGeneration tackingStockOne cPlatformConfigForSqueak methodRedirectPattern theVMGenerator tackingStockTwo + forTheImpatient + setGlobalOptions + cmakePrefixPath + cmakeIncludePath + cmakeLibraryPath + cmakeIncludeModules + cmakeCFlags + cmakeAddDefinitions + cmakeWriteDirectoriesDotCmake + cmakeIncludeDirectories + preferredIncludes + standardIncludes + setGlobalOptionsAfterDetermineSystem + extraVMSettings + setCoreSources + setPlatformSources + setCrossSources + setExtraSources + cmakeSetSourceFilesProperties + cmakeListAppendLINKLIBSelements + cmakeAddExecutableNameOptionSource + setExecutableOutputPath + addVMPlugins + 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 added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>preferredIncludes (in category 'pages') ----- + preferredIncludes + ^HelpTopic + title:'preferredIncludes' + contents: + 'SystemNavigation browseAllImplementorsOf: #preferredIncludes + + CPlatformConfig browseHierarchy + + As of CMakeVMMakerSqueak-tty.114 the method is a legacy method from the pharo CPlatformConfig. It is expect it (and this help page!!) will go away on a refactoring pass when the dependency on the pharo package is removed. + + + In the CPlatformConfigForSqueak>>preferredIncludes, we see the Method Redirect Pattern employed. Since this is for buildType #build, the method will re-route to self preferredIncludesBuild. + + SystemNavigation browseAllImplementorsOf: #preferredIncludesBuild + + We see that #preferredIncludesBuild is subclassed and implemented below the the platform level and down at the architecture/library location, one level above our new configuration. + + Linux64x86w32BitConfigUsrLib browseHierarchy + + The method itself creates a CMakeIncludeDirectories CMake template + + CMakeIncludeDirectories browse + + The class comment tells us that we can add custom include directories for CMake to use. + + The CMake template class initializes itself with some default data, which you can print out here: + + (CMakeIncludeDirectories new) content + + Since this is handled for us one level above our new configuration, we will leave this one untouched. If it turns out that we need to include some other directories, we can override the method.'! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>setCoreSources (in category 'pages') ----- + setCoreSources + ^HelpTopic + title:'setCoreSources' + contents: + 'SystemNavigation browseAllImplementorsOf: #setCoreSources: + + We see that this is a top-level Configuration method that writes a CMake Set(foo, bar) construct. + + There is nothing for us to do here.' + + + ! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>setCrossSources (in category 'pages') ----- + setCrossSources + ^HelpTopic + title:'setCrossSources' + contents: + 'SystemNavigation browseAllImplementorsOf: #setCrossSources: + + We see that this is a top-level Configuration method that writes a CMake Set(foo, bar) construct. + + There is nothing for us to do here.' + ! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>setExecutableOutputPath (in category 'pages') ----- + setExecutableOutputPath + ^HelpTopic + title:'setExecutableOutputPath' + contents: + 'SystemNavigation browseAllImplementorsOf: #setExecutableOutputPath + + We see that this is implemtented in CPlatformConfigForSqueak. + + It creates a CMakeSet object and sets the ''EXECUTABLE_OUTPUT_PATH'' variable to self outputDir + + SystemNavigation browseAllImplementorsOf: #outputDir + + This look customizable too, but I doubt we need it. + + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>setExtraSources (in category 'pages') ----- + setExtraSources + ^HelpTopic + title:'setExtraSources' + contents: + 'SystemNavigation browseAllImplementorsOf: #setExtraSources + + We see that this is a top-level Configuration method that writes a CMake Set(foo, bar) construct. + + There is nothing for us to do here. + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>setGlobalOptions (in category 'pages') ----- + setGlobalOptions + ^HelpTopic + title:'setGlobalOptions: self' + contents: + 'For this method there is nothing to do. Here is why. + + Let''s start by seeing what classes implement the method + + SystemNavigation browseAllImplementorsOf: #setGlobalOptions: + + We see that CPlatformConfigForSqueak implements it (The other classes are from the pharo package. These will go way after the dependency on the pharo code is factored out). + + Looking at it, we see that the method implements the Method Redirect pattern + + Since we have configured for buildType: #build, the Method Redirect Pattern will invoke the setGlobalOptionsBuild: aMaker method. + + So we look at the implementors of it.. + + SystemNavigation browseAllImplementorsOf: #setGlobalOptionsBuild: + + We see only CPlatformConfigForSqueak implements the method. Reading the method comments, we see that it generates CMakeLists.txt commands that span all platforms. + + No subclasses of CPlatformConfigForSqueak override it. + + There is nothing for us to override here. Let''s move on. + + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>setGlobalOptionsAfterDetermineSystem (in category 'pages') ----- + setGlobalOptionsAfterDetermineSystem + ^HelpTopic + title:'setGlobalOptionsAfterDetermineSystem' + contents: + 'SystemNavigation browseAllImplementorsOf: #setGlobalOptionsAfterDetermineSystem: + + + In the CPlatformConfigForSqueak>>setGlobalOptionsAfterDetermineSystem: aMaker, we see the Method Redirect Pattern employed. Since this is for buildType #build, the method will re-route to self setGlobalOptionsAfterDetermineSystemBuild + + SystemNavigation browseAllImplementorsOf: #setGlobalOptionsAfterDetermineSystemBuild: + + We see the CPLatformConfigForSqueak forces a subclass to implement it and the SqueakUnixConfig implements it. + + In SqueakUnixConfig a CMakeSet is created and initialized. You can see the resultant output by printing the below expression: + + ((CMakeSet new) variable:''CMAKE_C_COMPILER'' value:''gcc'') content + + Currently this is a platform level method, however, we can envision it being set lower when ''gcc'' is not the default compiler. + + For our purposes, there is nothing we need to do. + + '! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>setPlatformSources (in category 'pages') ----- + setPlatformSources + ^HelpTopic + title:'setPlatformSources' + contents:' + SystemNavigation browseAllImplementorsOf: #setPlatformSources: + + We see that this is a top-level Configuration method that writes a CMake Set(foo, bar) construct. + + There is nothing for us to do here.' + ! Item was added: + ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>standardIncludes (in category 'pages') ----- + standardIncludes + ^HelpTopic + title:'standardIncludes' + contents: + 'As of CMakeVMMakerSqueak-tty.114 the method is a legacy method from the pharo CPlatformConfig. It is expect it (and this help page!!) will go away on a refactoring pass when the dependency on the pharo package is removed. + + + SystemNavigation browseAllImplementorsOf: #standardIncludes + + CPlatformConfig browseHierarchy + + In the CPlatformConfigForSqueak>>standardIncludes, we see the Method Redirect Pattern employed. Since this is for buildType #build, the method will re-route to self standardIncludesBuild. + + SystemNavigation browseAllImplementorsOf: #standardIncludesBuild + + The SqueakUnixConfig just writes some debug messages. + + There is nothing for us to do here.'! Item was changed: ----- 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. + To do this by taking each statement in the CMakeVMGeneratorForSqueak>>generateByTemplate cascade in turn. + + '! Item was changed: ----- Method: SqueakUnixConfig>>cmakeWriteDirectoriesDotCmake: (in category 'cmake') ----- cmakeWriteDirectoriesDotCmake: aMaker |temp o| "We could put these inline, but other components include the directories.cmake file. So, we continue that convention" + self flag: 'tty, aMaker never used'. o := String new writeStream. temp := OrderedCollection new. temp addLast: ((CMakeSet new) variable: 'topDir' quotedValue: (self topDir fullName)); addLast: ((CMakeSet new) variable: 'buildDir' quotedValue: (self buildDir ifNil: ['${topDir}/build'] ifNotNil: [self buildDir fullName])); addLast: ((CMakeSet new) variable: 'thirdpartyDir' quotedValue: '${buildDir}/thirdParty'); addLast: ((CMakeSet new) variable: 'platformsDir' quotedValue: (self platformsDir)); addLast: ((CMakeSet new) variable: 'srcDir' quotedValue: (self srcDir pathName)); addLast: ((CMakeSet new) variable: 'srcPluginsDir' quotedValue: (pluginsDir ifNil: [ '${srcDir}/plugins' ])); addLast: ((CMakeSet new) variable: 'srcVMDir' quotedValue: '${srcDir}/vm'); addLast: ((CMakeSet new) variable: 'platformName' quotedValue: (self platformName)); addLast: ((CMakeSet new) variable: 'targetPlatform' quotedValue: '${platformsDir}/${platformName}'); addLast: ((CMakeSet new) variable: 'crossDir' quotedValue: '${platformsDir}/Cross'); addLast: ((CMakeSet new) variable: 'platformVMDir' quotedValue: '${targetPlatform}/vm}'); addLast: ((CMakeSet new) variable: 'outputDir' quotedValue: (self outputDir fullName)); addLast: ((CMakeSet new) variable: 'externalModulesDir' quotedValue: (self externalModulesDir)). temp do: [:each | o nextPutAll: (each content); cr]. self write: (o contents) toFile: 'directories.cmake'. (enabledebugmessages) ifTrue:[ templates addLast:((CMakeMessage new) message: (self class name), ' setDirectories: aMaker' ) ]. templates addLast: ((CMakeInclude new) file: 'directories.cmake'). !

1 0

VM Maker: CMakeVMMakerSqueak-tty.114.mcz
by commits＠source.squeak.org 29 May '16

29 May '16

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!

1 0

VM Maker: CMakeVMMakerSqueak-tty.113.mcz
by commits＠source.squeak.org 29 May '16

29 May '16

Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.113.mcz ==================== Summary ==================== Name: CMakeVMMakerSqueak-tty.113 Author: tty Time: 7 February 2016, 3:09:26.476102 pm UUID: 51e9d217-aa32-4b31-92cf-231c78a72f73 Ancestors: CMakeVMMakerSqueak-tty.112 Reviewing, editing Help after a loing time away. As I create a new Linux64x86w32BitSqueakCogSpurConfig I want the Example Workflow HelpTopic for a new configuration to accurately reflect the work to reproduce a CMake Configuration. Modest progress made. I blame my new cold. (:. =============== Diff against CMakeVMMakerSqueak-tty.112 =============== Item was changed: ----- Method: CMakeVMMakerSqueakBuildersHelp class>>buildTypes (in category 'pages') ----- buildTypes ^HelpTopic title:'Build types' contents: 'N.B. This query is dependent on the developer taking the time to maintain his Configuration correctly. If they do not, then invalid information will be conveyed. - For example, at the time of this writing, tty has completely dropped the ball on this. (: + Configurations are built over time. There is a possibility that a particulare build type is not available for a given Configuration simply because a developer has not gotten around to the task. - Configurations are built over time. There is a possibility that a particulare build type is not available for a given Configuration. For example, at the time of this writing, Linux64x86w32BitSqueakCogV3Config only has buildType #build available. + Since builds are sometimes not available and/or under development a developer *should* restrict what build types are avaiable for a configurations Builder by modifying the configuration''s "availableBuilds" method. - Since builds are sometimes not available and/or under development a developer may wish to restrict what build types are avaiable for a configurations Builder by modifying the configuration''s "availableBuilds" method. The purpose of this method is to present the end user with the avaiable buildTypes for a configuration category. when they invoke a Builder like so: SqueakLinux64x86w32CompatBuilder availableBuildTypesFor: #Linux64x86w32BitSqueakCogV3Config + The default is all buildTypes: - The default is all buildTypes: ^SqueakCMakeVMMakerAbstractBuilder default allBuildConfigurations + (NOTE: Why? Shouldn''t default be no build types? tty.) + You can display no buildTypes with: ^SqueakCMakeVMMakerAbstractBuilder default noBuildConfigurations. or you can customize it like so: ^(SqueakCMakeVMMakerAbstractBuilder default allBuildConfigurations copyWithoutAll: #( #assertWithHeartbeatTimer #debugWithHeartbeatTimer debugMultiThreadedFFI.....etc)) '! Item was changed: ----- Method: CMakeVMMakerSqueakBuildersHelp class>>builders (in category 'pages') ----- builders ^HelpTopic + title: 'Overview' - title: 'Builders' contents: + 'A CMakeVMakerSqueak Builder is both a ''query'' tool and a ''build'' tool. - ' - CMakeVMakerSqueak Builders provide a facade to CMakeVMmakerSqueak Configurations. + Builders provide a facade to CMakeVMmakerSqueak Configurations. - A Builder is both a ''query'' tool and a ''build'' tool. With a Builder, you can query its configurationsCategory''s Configurations + invoke a Configuration to generate CMake files or... + invoke a Configuration to generateSources which... - invoke a Configuration to generate CMake files or - invoke a Configuration to generateSources which invokes VMMaker.oscog to generate source Builders are concrete instances of the Abstract Base Class:SqueakCMakeVMMakerAbstractBuilder View SqueakCMakeVMMakerAbstractBuilder''s class comments for an overview of this tool. SqueakCMakeVMMakerAbstractBuilder browseHierarchy. + Information on creating your own is available via HelpBrowser openOn: CMakeVMMakerSqueakDeveloperHelp '! Item was changed: ----- Method: CMakeVMMakerSqueakBuildersHelp class>>generatingCMakeBuilds (in category 'pages') ----- generatingCMakeBuilds ^HelpTopic title: 'Generating CMake Builds' contents: + 'CMake Builds require CMake files. - ' - SqueakLinux64x86w32CompatBuilder configurationsCategory - SqueakLinux64x86w32CompatBuilder buildDirectory - SqueakLinux64x86w32CompatBuilder availableBuilds - SqueakLinux64x86w32CompatBuilder availableBuildTypesFor:(SqueakLinux64x86w32CompatBuilder availableBuilds at:1) - SqueakLinux64x86w32CompatBuilder sourceDirectoryFor:(SqueakLinux64x86w32CompatBuilder availableBuilds at:1) + We generate those files using a Builder. + + In the following message sends we are asking Builder to instruct a Configuration to... + configure itself for a specific build type + debug trace messages in its output. + output itself as CMake. + + SqueakLinux64x86w32CompatBuilder + configureA: #Linux64x86w32BitSqueakCogV3Config forBuildType:#build; + enableMessageTracking: true; + generateByTemplate. + + + '! Item was added: + ----- Method: CMakeVMMakerSqueakBuildersHelp class>>overview (in category 'pages') ----- + overview + ^HelpTopic + title: 'Overview' + contents: + 'A CMakeVMakerSqueak Builder is both a ''query'' tool and a ''build'' tool. + + Builders provide a facade to CMakeVMmakerSqueak Configurations. + + With a Builder, you can + query its configurationsCategory''s Configurations + invoke a Configuration to generate CMake files or... + invoke a Configuration to generateSources which... + invokes VMMaker.oscog to generate source + + Builders are concrete instances of the Abstract Base Class:SqueakCMakeVMMakerAbstractBuilder + Browse its class comment an heirarchy to get a feel for it. + + HelpBrowser openOn: SqueakCMakeVMMakerAbstractBuilder + SqueakCMakeVMMakerAbstractBuilder browseHierarchy. + + Information on creating your own is available via HelpBrowser openOn: CMakeVMMakerSqueakDeveloperHelp + TODO: Fix above sentence to point to something useful. + + '! Item was changed: ----- Method: CMakeVMMakerSqueakBuildersHelp class>>pages (in category 'accessing') ----- pages + ^#(overview queryingBuilders buildTypes generatingCMakeBuilds) + + "#(overview queryingBuilders buildTypes generatingCMakeBuilds scratch)"! - ^#(builders queryingBuilders buildTypes generatingCMakeBuilds scratch)! Item was changed: ----- Method: CMakeVMMakerSqueakBuildersHelp class>>queryingBuilders (in category 'pages') ----- queryingBuilders ^HelpTopic title: 'Querying Builders' contents: + 'You can query Builders for Configuration information for a specific platform. - ' - You query Builders for Configuration information for a specifi platform. + SqueakCMakeVMMakerAbstractBuilder availableBuildConfigurationsFor: ''CMakeVMMakerSqueak-Linux32x86''. + SqueakCMakeVMMakerAbstractBuilder availableBuildConfigurationsFor: ''CMakeVMMakerSqueak-MacOSX32x86''. + SqueakCMakeVMMakerAbstractBuilder allBuildTypes - SqueakLinux64x86w32CompatBuilder configurationsCategory - SqueakLinux64x86w32CompatBuilder buildDirectory - SqueakLinux64x86w32CompatBuilder availableBuilds - SqueakLinux64x86w32CompatBuilder availableBuildTypesFor:(SqueakLinux64x86w32CompatBuilder availableBuilds at:1) - SqueakLinux64x86w32CompatBuilder sourceDirectoryFor:(SqueakLinux64x86w32CompatBuilder availableBuilds at:1) + SqueakLinux64x86w32CompatBuilder configurationsCategory. + SqueakLinux64x86w32CompatBuilder buildDirectory. + SqueakLinux64x86w32CompatBuilder availableBuildConfigurations a SortedCollection(#Linux64x86w32BitSqueakCogV3Config). + SqueakLinux64x86w32CompatBuilder availableBuildTypesFor:(SqueakLinux64x86w32CompatBuilder availableBuildConfigurations at:1). + SqueakLinux64x86w32CompatBuilder sourceDirectoryFor:(SqueakLinux64x86w32CompatBuilder availableBuildConfigurations at:1). + + + The hope is that an app like Seaside would autogenerate build configurations while intelligently selecting/de-selecting based on the systems built-in configuration. + + ToolSet browseMessageCategory: ''queries'' inClass: SqueakCMakeVMMakerAbstractBuilder'! - '! Item was changed: ----- Method: CMakeVMMakerSqueakConfigurationsHelp class>>overview (in category 'pages') ----- overview ^HelpTopic title:'Overview' contents: + 'CMakeVMMakerSqueak Configurations. encapsulate CMake output. - ' 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 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. - Configurations can exclude themselves from being built by Builders. - Configurations can exclude themselves from supporting particular buildTypes. 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 added: + ----- Method: CMakeVMMakerSqueakDesignPatternsHelp class>>priority (in category 'accessing') ----- + priority + + ^ 8! Item was changed: ----- Method: CMakeVMMakerSqueakDeveloperHelp class>>pages (in category 'pages') ----- pages + ^#( CMakeVMMakerSqueakOverviewHelp CMakeVMMakerSqueakBuildersHelp CMakeVMMakerSqueakConfigurationsHelp CMakeVMMakerSqueakGeneratorsHelp CMakeVMMakerSqueakTemplatesHelp CMakeVMMakerSqueakDesignPatternsHelp CMakeVMMakerSqueakHistoryHelp ) + + + "#(CMakeVMMakerSqueakHistoryHelp CMakeVMMakerSqueakConfigurationsHelp CMakeVMMakerSqueakOverviewHelp CMakeVMMakerSqueakGeneratorsHelp CMakeVMMakerSqueakTemplatesHelp CMakeVMMakerSqueakBuildersHelp CMakeVMMakerSqueakDesignPatternsHelp configDotCmake looseEnds plugins pthreads templates tests )"! - ^#(CMakeVMMakerSqueakHistoryHelp CMakeVMMakerSqueakOverviewHelp CMakeVMMakerSqueakConfigurationsHelp CMakeVMMakerSqueakTemplatesHelp CMakeVMMakerSqueakGeneratorsHelp CMakeVMMakerSqueakBuildersHelp CMakeVMMakerSqueakDesignPatternsHelp configDotCmake looseEnds plugins pthreads templates tests )! Item was added: + ----- Method: CMakeVMMakerSqueakDeveloperHelp class>>priority (in category 'accessing') ----- + priority + + ^ 2! Item was changed: ----- Method: CMakeVMMakerSqueakExampleWorkflowHelp class>>bookName (in category 'accessing') ----- bookName + ^'Example Workflow: End User'! - ^'Example Workflow'! Item was changed: ----- Method: CMakeVMMakerSqueakExampleWorkflowHelp class>>examiningOutput (in category 'pages') ----- examiningOutput + "This method was automatically generated. Edit it using:" + "a HelpBrowser edit: #examiningOutput" ^HelpTopic title: 'Examining Output' + contents: + 'TODO: tty fix apperent but in build directory as it is outputing to DO THIS NEXT /cmake.build.linux64x86w32BitCompatibility/squeak.cog.v3/build/ - contents: - 'TODO: tty fix apperent but in build directory as it is outputing to /cmake.build.linux64x86w32BitCompatibility/squeak.cog.v3/build/ and not cmake.build.linux32_64x86 Examining the output requires two queries (both intuitive, via the intention revealing names of the Builder and Configuration) First, we ask the builder where it has its Configurations put their output: SqueakLinux64x86w32CompatBuilder buildDirectory --> ''cmake.build.linux32_64x86'' The Linux32x86SqueakCogV3Config writes itself to a directory that matches its [cmake.Platform]/[Language].[VM].[MemoryModel]/[BuildType] On my system that is: ~./..../cogVMMaker/oscogvm/cmake.[Platform]/[Language].[VM].[MemoryModel]/build i.e. ~./..../cogVMMaker/oscogvm/cmake.build.linux32_64x86/squeak.cog.v3/build I open a terminal and navigate to that directory: cd ~./..../cogVMMaker/oscogvm/cmake.build.linux32_64x86/squeak.cog.v3/build and list the contents bash-4.2$ ls ADPCMCodecPlugin LICENSE.txt SurfacePlugin AsynchFilePlugin LargeIntegers Utils.cmake B2DPlugin LocalePlugin ZipPlugin BMPReadWriterPlugin MIDIPlugin build.cmake BitBltPlugin Matrix2x3Plugin build.sh CMakeLists.txt MiscPrimitivePlugin config.cmake CroquetPlugin Mpeg3Plugin config.in DSAPrims PLUGINS.txt directories.cmake DropPlugin Plugins.cmake sqNamedPrims.h FFTPlugin SecurityPlugin testDoubleWordAlignment.c FileCopyPlugin SerialPlugin testDoubleWordOrder.c FilePlugin SocketPlugin testLanginfoCodeset.c FloatArrayPlugin SoundCodecPrims vm-display-X11 FloatMathPlugin SoundGenerationPlugin vm-display-null JoystickTabletPlugin SoundPlugin vm-sound-ALSA Klatt StarSqueakPlugin vm-sound-null .... (NOTE TODO tty: build a query to have a configuration return its build directory path.) + !!' readStream nextChunkText! - ' - - - ! Item was added: + ----- Method: CMakeVMMakerSqueakExampleWorkflowHelp class>>priority (in category 'pages') ----- + priority + + ^ 3! Item was changed: ----- Method: CMakeVMMakerSqueakExampleWorkflowHelp class>>selectConfiguration (in category 'pages') ----- selectConfiguration ^HelpTopic title: 'Select a Configuration' contents: 'The Configuration Linux64x86w32BitSqueakCogV3Config is available for my platform. (i.e. a developer has done the work of encapsulating the custom CMake for us). As stated before, I can view what Configurations are available for a platform by asking the platform Builder what it has available: SqueakLinux64x86w32CompatBuilder availableBuildConfigurations. + As of this writing the Linux64x86w32BitSqueakCogV3Config is available and I decide to use it. - As of this writing the Linux64x86w32BitSqueakCogV3Config is available and I decide on it. Note that the class name of the Configuration is intention-revealing. It is a Configuration for the Linux 64 platform with 32 Bit compatibility libs that encapsulates the CMake required to build the Squeak Cog V3 virtual machine. From this convention, The organization of configurations is straight-forward: CPlatformConfigForSqueak browseHierarchy Linux64x86w32BitSqueakCogV3Config browseHierarchy ' ! Item was added: + ----- Method: CMakeVMMakerSqueakHistoryHelp class>>priority (in category 'pages') ----- + priority + + ^ 7! Item was changed: ----- Method: CMakeVMMakerSqueakOverviewHelp class>>namingConventions (in category 'pages') ----- namingConventions + "This method was automatically generated. Edit it using:" + "a HelpBrowser edit: #namingConventions" ^HelpTopic + title: 'Naming Conventions' + contents: - title:'Naming Conventions' - contents: '[PLATFORM][Language][VM][Memory Manager][BuildType][foo] IS the naming convention for CMakeVMMakerSqueak The convention is a bottom-up design starting with Eliot Miranda''s Cog layout at http://www.squeakvm.org/svn/squeak/branches/Cog/ 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] It is this form that drives a parallel naming convention and directory structure in CMakeVMMakerSqueak. The parallel directory structure simply prefixes a ''cmake." to the directory name. cmake.build.[PLATFORM]/ |-- [Language].[VM].[Memory Manager] | |-- [BuildType] Builders have the form: Squeak[Platform]Builder. Example: SqueakBSD32x86Builder AbstractBaseClass Configurations have the form: [Optional Prefix][Platform]Config. Example: Linux32x86Config + Concrete Configurations have the form: [Optional Prefix]][Platform] [Language] [VM] [MemoryManager] [Optional Suffix] Config - Concrete Configurations have the form: [Optional ]Prefix][PLATFORM].[Language].[VM].[Memory Manager][Suffix][Optional Foo] Linux32x86SqueakCogV3Config When the Linux32x86SqueakCogV3Config is configured for the buildType #build.debug it will map its output to cmake.build.linux32x86/squeak.cog.v3/build.debug/ The naming convention for Configurations takes the following form: [Optional Prefix]][Platform] [Language] [VM] [MemoryManager] [Optional Suffix] Config. As of 2014.12.09 the possible combinatons are: [Prefix][Platform][Newspeak | Squeak][Cog | Sista | Stack][V3 | Spur][Foo]Config. + !!' readStream nextChunkText! - '! Item was changed: ----- Method: CMakeVMMakerSqueakOverviewHelp class>>overview (in category 'pages') ----- overview ^HelpTopic title:'Overview' contents: '"CMake drives development." Keeping the above statement in mind is the key to this package. What we are looking for is a CMake system that correctly builds a virtual machine on a given platform. We then encapsulate that CMake system state in CMakeVMMakerSqueak Configurations. The end user can then reproduce that CMake system on their platform. Hopefully this package makes the above process predictable and somewhat sane. Towards that end, this system does the following : Stores CMake configuration in concrete subclasses of CPlatformConfigForSqueak in a predicatable manner. Provides methods for extracting the CMake configuration from those classes. Provides a (hopefully) newbie friendly Facade for extracting the CMake configuration via Builders (Concrete subclasses of SqueakCMakeVMMakerAbstractBuilder) Provides (for the configuration developer) CMake command wrapper code in subclasses of CMakeTemplate. Proves to be scriptable such that generating the CMake output can be automated (or extracted from a Seaside website). As the SqueakVM community gains experience with CMake, I expect the quality of the generated CMake output to improve considerably. CMake is a BIG system with LOTS of stuff in it. Storing the knowledge we gain in our Squeak classes should make things a lot easier on us. The heart of the package is CMakeGeneratorForSqueak and its two subclasses CMakeVMGeneratorForSqueak and CMakePluginGeneratorForSqueak. CMakeVMGeneratorForSqueak collects information from subclasses of CPlatformConfigForSqueak, CMThirdpartyLibrary and InterpreterPlugins and writes it out to CMake files and associated directories. From there, the user invokes cmake and make using a generated build.sh script. The programmer directs the flow of the generator by coding a subclass of CPlatformConf, setting it up correctly and asking it to generate itself. The configuration then invokes the CMakeGeneratorForSqueak passing itself as an argument. + The VMGeneratator extracts the information and utilizes VMPluginGenerator to generate plugin stuff, the CPlatformConf to generate other stuff and CMThirdPartyLibrary''s to generate other stuff. (TODO: tighten up this language) - The VMGeneratator extracts the information and utilizes VMPluginGenerator to generate plugin stuff, the CPlatformConf to generate other stuff and CMThirdPartyLibrary''s to generate other stuff. The end result is a CMake evironment that is set up to correctly build a VM Concrete implementations of SqueakCMakeVMMakerAbstractBuilder provide an invokation facade and configuration query capabilities. '! Item was changed: ----- Method: CMakeVMMakerSqueakOverviewHelp class>>prerequisites (in category 'pages') ----- prerequisites ^HelpTopic title:'Prerequisites' contents: + 'As of 2016.02.06 CMakeVMMakerSqueak depends on CMakeVMMaker (a pharo implementation). This dependency will be broken in due course. + TODO: Break this dependency TTY - 'The CMakeVMMakerSqueak depends on CMakeVMMaker (a pharo implementation) CMake from http://www.cmake.org/ is required to process the output of this package. This package was written using cmake version 2.8.12 '! Item was changed: ----- Method: CMakeVMMakerSqueakStartHereHelp class>>nextSteps (in category 'pages') ----- nextSteps ^HelpTopic title: 'Next Steps' contents: + 'The Help Topic entitled "Example Workflow: End User" will walk you through an example workflow as executed on a GNU Linux system with the standard development tools. Macintosh and Windows dev tools will differ (N.B. tty The primary difference is that they have not been written yet (: ). - 'The next Help Topic entitled "Example Workflow" will walk you through an example workflow as executed on a GNU Linux system with the standard development tools. Macintosh and Windows dev tools will differ (N.B. tty The primary difference is that they have not been written yet (: ). + The Help Topic entitled "Developer Guide" will explain the design of and how to add and modify the components of the CMakeVMMakerSqueak system. '! Item was changed: ----- Method: CMakeVMMakerSqueakStartHereHelp class>>overview (in category 'pages') ----- overview ^HelpTopic title: 'Overview' contents: 'CMakeVMMakerSqueak is a collection of tools for generating CMake files. The high-level workflow is: 1. Instruct CMakeVMMakerSqueak to generate CMake build directories and CMake configuration files. 2. Invoke the ''cmake'' command at the top level of the generated cmake build tree + - 3. CMake configures and outputs the build system files for that platform. 4. The user invokes the native build system. + 5. The native build system compiles a VM. - 5. A VM is produced under a ~/...../''cmake.platforms'' subdirectory. + The ''Example Workflow: End User'' page in this Help book provides an example of the above workflow with minimal explanation. - The ''Example Workflow'' page in this Help book provides an example of the above workflow with minimal explanation. + In-depth explanations of the system(s), tools and how to use them, see the ''CMakeVMMaker Developer Guide'''! Item was added: + ----- Method: CMakeVMMakerSqueakStartHereHelp class>>priority (in category 'pages') ----- + priority + + ^ 1! Item was changed: ----- Method: CMakeVMMakerSqueakStartHereHelp class>>requirements (in category 'pages') ----- requirements + "This method was automatically generated. Edit it using:" + "a HelpBrowser edit: #requirements" ^HelpTopic title: 'Requirements' + contents: + 'CMakeVMakerSqueak (as of 2014.12.09) depends on the Pharo package CMakeVMMaker. This dependency will be broken in a future release. + A (possibly out-of-sync) Monticello version is available at: - contents: - 'CMakeVMakerSqueak (as of 2014.12.09) depends on the Pharo package CMakeVMMaker. A (possibly out-of-sync) Monticello version is available at: MCHttpRepository location: ''http://source.squeak.org/VMMaker'' user: '''' password: '''' CMakeVMMakerSqueak is available at: MCHttpRepository location: ''http://source.squeak.org/VMMaker'' user: '''' password: '''' + CMake is available from http://www.cmake.org. The version of CMake used as of 2014.12.09 is 2.8.12 CMake provides a cmake_minimum_required(..) command, so newer versions should be ok. - The next Help Topic entitled "Example Workflow" will walk you through an example workflow is presented on a GNU Linux system with the standard development tools. Macintosh and Windows dev tools will differ. + + !!' readStream nextChunkText! - '! Item was changed: ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>createTheConfiguration (in category 'pages') ----- createTheConfiguration ^HelpTopic title:'Create the Configuration' contents: 'Our new Concrete Configuration must be created as a subclass of our Platform''s Abstract Base Class. + SInce I am creating a Squeak Cog Spur config for the CMakeVMMakerSqueak-Linux64X86-32BitCompatibility Platform I choose the name: - SInce I am creating a Squeak Cog V3 config for the Linux32x86 Platform I choose the name: + Linux64x86w32BitSqueakCogSpurConfig. - Linux32x86SqueakCogV3Config. (For a discussion on naming conventions evaluate: HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp ) + To create it, I must subclass the Abstract Base Class for my Platform like so: - To create it, I subclass the Abstract Base Class for my Platform like so: + Linux64x86w32BitConfigUsrLib subclass: #Linux64x86w32BitSqueakCogSpurConfig - Linux32x86Config subclass: #Linux32x86SqueakCogV3Config instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' + category: ''CMakeVMMakerSqueak-Linux64X86-32BitCompatibility'' - category: ''CMakeVMMakerSqueak-Linux32x86'' However, being lazy, I am going to copy an existing Configuration that is similar to what I want. Today I choose Linux64x86w32BitSqueakCogV3Config from the CMakeVMMakerSqueak-Linux64X86-32BitCompatibility Platform category + I copy the class and then change its name, parent and class category to get: - I copy the class and then change its parent and class category to get: + Linux64x86w32BitConfigUsrLib subclass: #Linux64x86w32BitSqueakCogSpurConfig - Linux32x86Config subclass: #Linux32x86SqueakCogV3Config instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' + category: ''CMakeVMMakerSqueak-Linux64X86-32BitCompatibility'' - category: ''CMakeVMMakerSqueak-Linux32x86'' - At this point I re-run all my Tests. For me, all tests pass. - I then query by Builder to see if it sees the new Configuration in the platform: + SqueakLinux64x86w32CompatBuilder configurationsCategory + --> ''CMakeVMMakerSqueak-Linux64X86-32BitCompatibility'' - SqueakLinux32x86Builder configurationsCategory - --> ''CMakeVMMakerSqueak-Linux32x86'' + SqueakLinux64x86w32CompatBuilder availableBuildConfigurations + --> a SortedCollection(#Linux64x86w32BitSqueakCogSpurConfig #Linux64x86w32BitSqueakCogV3Config) + "Here we see our new Configuration is visible to the Builder" - SqueakLinux32x86Builder availableBuildConfigurations - --> a SortedCollection(#Linux32x86SqueakCogV3Config) "Here we see our new Configuration is visible to the Builder" + SqueakLinux64x86w32CompatBuilder unAvailableBuildConfigurations + --> a SortedCollection(#Linux64x86w32BitConfigUsrLib #Linux64x86w32BitConfigUsrLib32) "Our Abstract Base Classes are not available to be built" - SqueakLinux32x86Builder unAvailableBuildConfigurations - --> a SortedCollection(#Linux32x86Config) "The Abstract Base Class is not available to be built" + SqueakLinux64x86w32CompatBuilder availableBuildTypesFor: #Linux64x86w32BitSqueakCogSpurConfig + --> an OrderedCollection(#build #buildAssert) "The Configuration I copied has two Build Types coded and available." - SqueakLinux32x86Builder availableBuildTypesFor: #Linux32x86SqueakCogV3Config - --> an OrderedCollection(#build) "The Configuration I copied has one Build Type coded/available." + SqueakLinux64x86w32CompatBuilder sourceDirectoryFor:#Linux64x86w32BitSqueakCogSpurConfig + --> "src" "Where the vm source code is located (we will be changing this)" - SqueakLinux32x86Builder sourceDirectoryFor:#Linux32x86SqueakCogV3Config - --> "src" "Where the vm source code is located" My new configuration is correctly named and in the correct place. + At this point I re-run all my Tests. + TestRunner open + For me, all tests pass. + + In the next topic we cover how to hide our new Configuration from a builder. + ' ! Item was changed: ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>excludingConfigFromBuilds (in category 'pages') ----- excludingConfigFromBuilds ^HelpTopic title:'Excluding a Config From Builds' contents: 'Configurations can hide themselves from , or make themselves visible to Builders via their ''excludeFromBuild'' method. excludeFromBuild ^false "build this configuration" " ^true do not build this configuration" + In our case, the Builder shows us that Linux32x86SqueakCogSpurConfig is capable of being built (I had copied an existing, working Configuration): - This functionality is included with an eye towards easing automated builds for all platforms and configurations. + SqueakLinux64x86w32CompatBuilder availableBuildConfigurations + --> a SortedCollection(#Linux64x86w32BitSqueakCogSpurConfig #Linux64x86w32BitSqueakCogV3Config) - In our case, the Builder shows us that Linux32x86SqueakCogV3Config is capable of being built (I had copied an existing, working Configuration): - SqueakLinux32x86Builder availableBuildConfigurations - --> an OrderedCollection(#Linux32x86SqueakCogV3Config) To exclude it, override (or alter) the Configurations ''excludeFromBuild'' method + Linux64x86w32BitSqueakCogSpurConfig >>excludeFromBuild - Linux32x86SqueakCogV3Config >>excludeFromBuild "over-ride to exclude yourself from a build" ^true And the Configuration is hidden from the Builder... + SqueakLinux64x86w32CompatBuilder availableBuildConfigurations + --> a SortedCollection(#Linux64x86w32BitSqueakCogV3Config) - SqueakLinux32x86Builder availableBuildConfigurations - --> an OrderedCollection() However, since I am developing locally, I need it to be visible to the Builder , so I set it as so: + Linux64x86w32BitSqueakCogSpurConfig >>excludeFromBuild - Linux32x86SqueakCogV3Config >>excludeFromBuild "over-ride to exclude yourself from a build" ^false And my Builder can see it again... + SqueakLinux64x86w32CompatBuilder availableBuildConfigurations + --> a SortedCollection(#Linux64x86w32BitSqueakCogSpurConfig #Linux64x86w32BitSqueakCogV3Config) - SqueakLinux32x86Builder availableBuildConfigurations - an OrderedCollection(#Linux32x86SqueakCogV3Config) N.B. tty. My opinion is that this is a weak way of doing this, but I have not thought through how to do this elegantly. + This functionality is included with an eye towards easing automated builds for all platforms and configurations.'! - - - - - - - '! Item was changed: ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>identifyBuilder (in category 'pages') ----- identifyBuilder ^HelpTopic title:'Identify Builder' contents: 'My new Configuration will be managed by a Builder. Builders are located in the CMakeVMMakerSqueak-Builder class category. Builders are subclasses of SqueakCMakeVMMakerAbstractBuilder. + SqueakCMakeVMMakerAbstractBuilder browseHierarchy Builders are named according to the Platform they manage. (For a discussion on naming conventions evaluate: HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp ) Builders manage configurations for one Platform in one class category. - My platform is Linux 32x86. + My platform is Linux Linux64x86 with 32 bit compatability libs stored in /usr/lib (other linux use /usr/lib32 for this.) - I suspect that the SqueakLinux32x86Builder as the Builder that will manage my new configuration. + I suspect that the SqueakLinux64x86w32CompatBuilder as the Builder that will manage my new configuration. + I confirm this by sending it the ''configurationsCategory'' message as shown below: + SqueakLinux64x86w32CompatBuilder configurationsCategory + -->''CMakeVMMakerSqueak-Linux64X86-32BitCompatibility'' <---this is the correct class category for my Platform. - SqueakLinux32x86Builder configurationsCategory - -->''CMakeVMMakerSqueak-Linux32x86'' <---this is the correct class category for my Platform. This is correct Builder for my new Configuration. I can query the Builder for some more information: + SqueakLinux64x86w32CompatBuilder availableBuildConfigurations + a SortedCollection(#Linux64x86w32BitSqueakCogV3Config) <--A Cog V3 configuration exists. - SqueakLinux32x86Builder availableBuildConfigurations - a SortedCollection() <--there are no concrete configurations in place as of this writing. + SqueakLinux64x86w32CompatBuilder unAvailableBuildConfigurations + --> a SortedCollection(#Linux64x86w32BitConfigUsrLib #Linux64x86w32BitConfigUsrLib32) + <--these are platform specific Abstract Base Classes. Abstract Base Classes cannot be built, hence they are unavailable. - SqueakLinux32x86Builder unAvailableBuildConfigurations - a SortedCollection(#Linux32x86Config) <--this is my Abstract Base Class. Abstract Base Classes cannot be built, hence they are unavailable. + SqueakLinux64x86w32CompatBuilder buildDirectory + -->''cmake.build.linux64x86w32BitCompatibility'' <--this matches my platform - SqueakLinux32x86Builder buildDirectory - -->''cmake.build.linux32x86'' <--this matches my platform + We will be using the SqueakLinux64x86w32CompatBuilder in tandem with Tests during Configuration development.' - We will be using the SqueakLinux32x86Builder in tandem with Tests during Configuration development.' ! Item was changed: ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>identifyPlatform (in category 'pages') ----- identifyPlatform ^HelpTopic title:'Identify Platform' contents: + 'My target platform is 64 bit Linux on X86 with 32 bit compatibility libraries stored in /usr/lib. - 'My target platform is Linux 32 bit x86. I identify my Platform in the existing CMakeVMMakerSqueak-xyz class categories. - I choose the CMakeVMMakerSqueak-Linux32x86 as the location for my new Configuration. If I wanted a configuration for MacOSX32x86, I would place my configuration in CMakeVMMakerSqueak-MacOSX32x86. If SunOSx3x86 then CMakeVMMakerSqueak-SunOS32x86. + etc. - etc, etc. + For a discussion on naming conventions evaluate: - - (For a discussion on naming conventions evaluate: HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp - ) - - '! Item was changed: ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>identifyPlatformAbstractBaseClass (in category 'pages') ----- identifyPlatformAbstractBaseClass ^HelpTopic title:'Identify Abstract Base Class ' contents: 'My new configuration must be a subclass of my Platform''s Abstract Base Class. + A Platform Abstract Base Class encapsulates common platform information. - In class category CMakeVMMakerSqueak-Linux32x86 the Abstract Base Class is Linux32x86Config + In CMakeVMMakerSqueak-Linux64X86-32BitCompatibility class category I see two Abstract Base Classes (typically there is only one). They are: - Examples of Abstract Base Classes in other class categories (category->Abstract Base Class) include: + Linux64x86w32BitConfigUsrLib + Linux64x86w32BitConfigUsrLib32 + + The Suffixes ''UsrLib'' and ''UsrLib32'' refer to the location of the 32 bit compatablity libs. + On my system they are in /usr/lib, so I choose Linux64x86w32BitConfigUsrLib as my Abstract Base Class + + Examples of Abstract Base Classes in other class categories include: + CMakeVMMakerSqueak-BSD32x86 -> SqueakBSD32x86Config CMakeVMMakerSqueak-IA32-Bochs -> SqueakIA32BochsConfig CMakeVMMakerSqueak-IOS -> SqueakIOSConfig CMakeVMMakerSqueak-IOS -> SqueakIOSConfig CMakeVMMakerSqueak-Linux32ARMv6 -> Linux32ARMv6Config + CMakeVMMakerSqueak-Linux64x64 -> Linux64x64Config - CMakeVMMakerSqueak-Linux64X86-32BitCompatibility -> Linux64x86w32BitConfig - CMakeVMMakerSqueak-LinuxX86-64 -> Linux64Config CMakeVMMakerSqueak-MacOSPowerPC -> SqueakMacOSXPowerPCConfig CMakeVMMakerSqueak-MacOSX32x86 -> SqueakMacOSX32x86Config CMakeVMMakerSqueak-SunOS32x86 -> SqueakSunOS32x86Config CMakeVMMakerSqueak-Win32x86 -> SqueakWin32x86Config I can identify the Abstract Base Class in several ways + 1. It is a topmost class in the class heirarchy for that platform/class category - 1. It is the topmost class in the class category for that platform 2. It is named after its platform 3. It answers #true to the message isAbstractBaseClass + Linux64x86w32BitConfigUsrLib isAbstractBaseClass - Linux32x86Config isAbstractBaseClass --> true - 4. Its class initialize method sets its isAbstractBaseClass class instance variable to #true - 5. It is the only Abstract Base Class in its immediate class heirarchy. + In this workflow example I ideduce that the AbstractBaseClass for my Platform is Linux64x86w32BitConfigUsrLib'! - My new configurations will be a subclass of the AbstractBaseClass for my platform. - - In this workflow example the AbstractBaseClass for my Platform is Linux32x86Config - - '! Item was changed: ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>overview (in category 'pages') ----- overview ^HelpTopic title:'Overview' contents: + 'This Help Topic presents the workflow the author used in creating the Squeak, Cog, Spur CMake configuration for a 64 bit Slackware 14.1 system.with 32 bit compatability libs in /usr/lib - 'This Help Topic presents the workflow the author used in creating the Squeak, Cog, V3 CMake configuration for a pure 32 bit Slackware 14.1 system. - The steps involved should be the same for any platform.'! 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 - '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) - SqueakLinux32x86Builder availableBuildTypesFor: #Linux32x86SqueakCogV3Config - -->an OrderedCollection(#build) - In our Abstract Base Class (Which, you recall cannot be buil)for our Platform, we default to all build types. + In our Abstract Base Class (Which, you recall cannot be buil)for our Platform, we default to no build types. - Linux32x86Config>>availableBuildTypes - ^SqueakCMakeVMMakerAbstractBuilder default allBuildTypes + Linux64x86w32BitConfigUsrLib>>availableBuildTypes + ^SqueakCMakeVMMakerAbstractBuilder default noBuildTypes - Evaluating the return gives us: + + 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 - Linux32x86SqueakCogV3Config >> 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 - Here I show what happens when I subtract more from the available pool. Here I set my Configuration to only omit 2 build types: 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 developr to set it up. If there is an elegant way to do this , I am for it. '! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirARMv6 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirARMv6 (in category 'cmake directory ') ----- dirARMv6 ^'cmake.build.arm.v6'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirAndroid (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirAndroid (in category 'cmake directory ') ----- dirAndroid ^'Do Not Build. See Class Comment'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBSD32x86 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirBSD32x86 (in category 'cmake directory ') ----- dirBSD32x86 ^'cmake.build.bsd32x86'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuild (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuild (in category 'cmake directory ') ----- dirBuild ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #build! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildAssert (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildAssert (in category 'cmake directory ') ----- dirBuildAssert ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #buildAssert! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildAssertITimerHeartbeat (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildAssertITimerHeartbeat (in category 'cmake directory ') ----- dirBuildAssertITimerHeartbeat ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #buildAssertITimerHeartbeat! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildDebug (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildDebug (in category 'cmake directory ') ----- dirBuildDebug ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #debug! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildDebugITimerHeartbeat (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildDebugITimerHeartbeat (in category 'cmake directory ') ----- dirBuildDebugITimerHeartbeat ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #debugITimerHeartbeat! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildDebugMultiThreaded (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildDebugMultiThreaded (in category 'cmake directory ') ----- dirBuildDebugMultiThreaded ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #debugMultiThreaded! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildITimerHeartbeat (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildITimerHeartbeat (in category 'cmake directory ') ----- dirBuildITimerHeartbeat ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #buildITimerHeartbeat! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildLanguageVMMM (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildLanguageVMMM (in category 'cmake directory ') ----- dirBuildLanguageVMMM "the directory under buildPlatformDir example: newspeak.cog.spur. use squeak.cog.v3 as default" self subclassResponsibility! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildMultiThreaded (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildMultiThreaded (in category 'cmake directory ') ----- dirBuildMultiThreaded ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #buildMultiThreaded! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildMultiThreadedAssert (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildMultiThreadedAssert (in category 'cmake directory ') ----- dirBuildMultiThreadedAssert ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #buildMultiThreadedAssert! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildMultiThreadedDebug (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildMultiThreadedDebug (in category 'cmake directory ') ----- dirBuildMultiThreadedDebug ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #buildMultiThreadedDebug! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildPlatform (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildPlatform (in category 'cmake directory ') ----- dirBuildPlatform "the directory for the platform. example: build.linux32x86" self subclassResponsibility! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirIA32Bochs (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirIA32Bochs (in category 'cmake directory ') ----- dirIA32Bochs ^'cmake.build.ia32bochs'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirIOS (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirIOS (in category 'cmake directory ') ----- dirIOS ^'cmake.build.ios'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirInstall (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirInstall (in category 'cmake directory ') ----- dirInstall "the directory of the finished product.. the place where 'make install' puts stuff. SystemNavigation default browseMethodsWhoseNamesContain: 'outputDir' " self subclassResponsibility ! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirLinux32Armv6 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirLinux32Armv6 (in category 'cmake directory ') ----- dirLinux32Armv6 ^'cmake.build.linux32armv6'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirLinux32x86 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirLinux32x86 (in category 'cmake directory ') ----- dirLinux32x86 ^'cmake.build.linux32x86'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirLinux64x64 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirLinux64x64 (in category 'cmake directory ') ----- dirLinux64x64 ^'cmake.build.linux64x64'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirLinux64x86w32BitCompatibility (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirLinux64x86w32BitCompatibility (in category 'cmake directory ') ----- dirLinux64x86w32BitCompatibility ^'cmake.build.linux64x86w32BitCompatibility'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirMacOS (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirMacOS (in category 'cmake directory ') ----- dirMacOS ^'cmake.build.macos'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirMacOSPowerPC (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirMacOSPowerPC (in category 'cmake directory ') ----- dirMacOSPowerPC ^'cmake.build.macospowerpc'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirMacOSX32x86 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirMacOSX32x86 (in category 'cmake directory ') ----- dirMacOSX32x86 ^'cmake.build.macosx32x86'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirOutput (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirOutput (in category 'cmake directory ') ----- dirOutput ^'cmake.products'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirSource (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirSource (in category 'cmake directory ') ----- dirSource ^'src'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirSunOS32x86 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirSunOS32x86 (in category 'cmake directory ') ----- dirSunOS32x86 ^'cmake.build.sunos32x86'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirWin32x86 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>dirWin32x86 (in category 'cmake directory ') ----- dirWin32x86 ^'cmake.build.win32x86'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>externalModulesDir (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>externalModulesDir (in category 'cmake directory ') ----- externalModulesDir "answer the location in VM bundle, where plugins and rest of dynamic libs will be copied, " self subclassResponsibility! Item was changed: + ----- Method: CPlatformConfigForSqueak>>newspeakCogSpur (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>newspeakCogSpur (in category 'cmake directory ') ----- newspeakCogSpur ^'newspeak.cog.spur'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>newspeakCogV3 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>newspeakCogV3 (in category 'cmake directory ') ----- newspeakCogV3 ^'newspeak.cog.v3'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>newspeakSistaSpur (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>newspeakSistaSpur (in category 'cmake directory ') ----- newspeakSistaSpur ^'newspeak.sista.Spur'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>newspeakSistaV3 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>newspeakSistaV3 (in category 'cmake directory ') ----- newspeakSistaV3 ^'newspeak.sista.v3'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>newspeakStackSpur (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>newspeakStackSpur (in category 'cmake directory ') ----- newspeakStackSpur ^'newspeak.stack.spur'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>newspeakStackV3 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>newspeakStackV3 (in category 'cmake directory ') ----- newspeakStackV3 ^'newspeak.stack.v3'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>oscogvm (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>oscogvm (in category 'cmake directory ') ----- oscogvm ^'oscogvm'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>outputDirName (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>outputDirName (in category 'cmake directory ') ----- outputDirName ^ 'products'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>squeakCogSpur (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>squeakCogSpur (in category 'cmake directory ') ----- squeakCogSpur ^'squeak.cog.spur'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>squeakCogV3 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>squeakCogV3 (in category 'cmake directory ') ----- squeakCogV3 ^'squeak.cog.v3'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>squeakSistaSpur (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>squeakSistaSpur (in category 'cmake directory ') ----- squeakSistaSpur ^'squeak.sista.Spur'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>squeakSistaV3 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>squeakSistaV3 (in category 'cmake directory ') ----- squeakSistaV3 ^'squeak.sista.v3'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>squeakStackSpur (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>squeakStackSpur (in category 'cmake directory ') ----- squeakStackSpur ^'squeak.stack.spur'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>squeakStackV3 (in category 'cmake directory') ----- - ----- Method: CPlatformConfigForSqueak>>squeakStackV3 (in category 'cmake directory ') ----- squeakStackV3 ^'squeak.stack.v3'! Item was added: + Linux64x86w32BitConfigUsrLib subclass: #Linux64x86w32BitSqueakCogSpurConfig + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'CMakeVMMakerSqueak-Linux64X86-32BitCompatibility'! + + !Linux64x86w32BitSqueakCogSpurConfig commentStamp: '<historical>' prior: 0! + I am a configuration for 64 bit Linux with 32 Bit compatability libraries. + I have been tested with Slackware64 14.1 which uses /usr/lib for 32 bit compatability libs and /usr/lib64 for normal libs. + + If you have a machine which uses /usr/lib for 64 bit libs and /usr/lib32 for 32 bit compat libs then subclass me and modify (at least) the following methods: + + compilerFlags + externalLibraries + linkFlagsBuild + linkerFlags + + + SqueakLinux64x86w32CompatBuilder + configureABuildFor: #Linux64x86w32BitSqueakCogV3Config withBuildType: #build; + enableMessageTracking: true; + generateByTemplate. + + HelpBrowser openOn: CMakeVMMakerSqueakDeveloperHelp + + + Getting the UUIDPlugin to compile (not work, unfortunately, but compile) required modifying oscogvm/platforms/unix/plugins/acinclude.m4. + to read: (my Slackware system has <uuid> and uuidgen. then setting the + + # -*- sh -*- + + AC_MSG_CHECKING([for UUID support]) + AC_TRY_COMPILE([#include <sys/uuid.h>],[uuid_generatorxyz;],[ + AC_MSG_RESULT(yes) + AC_CHECK_LIB(uuid, uuid_generator_xyz,LIB_UUID="-luuid" ) + ],[ + AC_MSG_RESULT(no) + AC_MSG_CHECKING([for UUID support uuid/uuid.h] and uuid_generate) + AC_TRY_COMPILE([#include <uuid/uuid.h>],[uuid_generate;],[ + AC_MSG_RESULT(yes) + AC_CHECK_LIB(uuid, uuid_generate, LIB_UUID="-luuid")],[ + AC_MSG_RESULT(no) + AC_MSG_CHECKING([for UUID support uuid and uuidgen] ) + AC_TRY_COMPILE([#include <uuid.h>],[uuidgen;],[ + AC_MSG_RESULT(yes) + AC_CHECK_LIB(uuid, uuidgen, LIB_UUID="-luuid" )],[ + AC_MSG_RESULT(no) + AC_PLUGIN_DISABLE + ]) + ]) + ]) + + + + + #define HAVE_UUID_H 1 + #define HAVE_UUIDGEN 1 + + fl;ags in my configH method + + ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig class>>isAbstractBaseClass (in category 'as yet unclassified') ----- + isAbstractBaseClass + ^false + ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>availableBuildTypes (in category 'as yet unclassified') ----- + availableBuildTypes + "2.14.12.09 only buildType implemented is #build so I remove #build from the below OrderedCollection." + ^SqueakCMakeVMMakerAbstractBuilder default allBuildTypes copyWithoutAll: #( #buildAssertITimerHeartbeat #buildDebug #buildDebugITimerHeartbeat #buildITimerHeartbeat #buildMultiThreaded #buildMultiThreadedAssert #buildMultiThreadedDebug #buildNone)! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>cmakeAddDefinitionsBuild (in category 'cmake buildType redirects') ----- + cmakeAddDefinitionsBuild + |definitions| + definitions:=#( + '-DNDEBUG' + '-DDEBUGVM=0' + ' -DLSB_FIRST=1' + '-D_GNU_SOURCE' + '-D_FILE_OFFSET_BITS=64' + " '-DUSE_GLOBAL_STRUCT=0'" + '-DCOGMTVM=0') . + + (enabledebugmessages) + ifTrue:[ templates + addLast:((CMakeMessage new) message: (self class name) , 'cmakeAddDefinitionsBuild') + ] . + templates + addLast:((CMakeAddDefinitions new) definitions: definitions). + + " templates + addLast:((CMakeAddDefinitions new) definitions: (self compilerDefinitions asOrderedCollection)). <--this was the old pharo deprecated legacy code approach that is unsuitable for the multiple buildTypes each Configuration must support" + + ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>cmakeAddDefinitionsBuildAssert (in category 'cmake buildType redirects') ----- + cmakeAddDefinitionsBuildAssert + |definitions| + "copy-n-paste from /build.linux32x86/squeak.cog.v3/build.assert/mvm file" + definitions:=#( + '-DDEBUGVM=0' + '-D_GNU_SOURCE' + '-D_FILE_OFFSET_BITS=64' + '-DCOGMTVM=0' + ) . + + (enabledebugmessages) + ifTrue:[ templates + addLast:((CMakeMessage new) message: (self class name) , 'cmakeAddDefinitionsBuildAssert') + ] . + templates + addLast:((CMakeAddDefinitions new) definitions: definitions). + + " templates + addLast:((CMakeAddDefinitions new) definitions: (self compilerDefinitions asOrderedCollection)). <--this was the old pharo deprecated legacy code approach that is unsuitable for the multiple buildTypes each Configuration must support" + + ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>cmakeCFlagsBuild (in category 'cmake buildType redirects') ----- + cmakeCFlagsBuild + |cflags| + self flag:'tty'. "#build should have -O2" + cflags:= String streamContents: [:stream | (self compilerFlags) asStringOn: stream delimiter: ' ' ]. + cflags:='"', cflags, '"'. + (enabledebugmessages) + ifTrue:[ templates + addLast:((CMakeMessage new) message: (self class name) , 'cmakeCFlagsBuild') + ] . + templates + addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS' value: '${CMAKE_C_FLAGS} ', cflags ); + addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS_RELEASE' value: '${CMAKE_CXX_FLAGS_RELEASE} ', cflags ); + addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS_DEBUG' value: '${CMAKE_CXX_FLAGS_DEBUG} ',cflags); + addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS' value: '${CMAKE_CXX_FLAGS} ', cflags ); + addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS_RELEASE' value: '${CMAKE_CXX_FLAGS_RELEASE} ', cflags ); + addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS_DEBUG' value: '${CMAKE_CXX_FLAGS_DEBUG} ', cflags ). + + (enabledebugmessages) "take a peek at em" + ifTrue:[ templates + addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}'); + addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS_DEBUG=${CMAKE_CXX_FLAGS_DEBUG}'); + addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS_RELEASE=${CMAKE_CXX_FLAGS_RELEASE}'); + addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS=${CMAKE_C_FLAGS}'); + addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS_DEBUG=${CMAKE_C_FLAGS_DEBUG}'); + addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS_RELEASE=${CMAKE_C_FLAGS_RELEASE}') + ] . + + + ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>cmakeSetSourceFilesPropertiesBuild (in category 'cmake buildType redirects') ----- + cmakeSetSourceFilesPropertiesBuild + |cflags| + cflags:=String streamContents: [:stream | (self compilerFlags) asStringOn: stream + delimiter: ' ' ]. + cflags := '"' , cflags , '"'. + (enabledebugmessages) + ifTrue:[ templates + addLast:((CMakeMessage new) message: (self class name) , 'cmakeSetSourceFilesPropertiesBuild') + ] . + templates + addLast:((CMakeSetSourceFilesProperties new) + files: (OrderedCollection with: '${srcVMDir}/cogit.c') + propertiesandvalues:{'COMPILE_FLAGS' . cflags}); + addLast:((CMakeSetSourceFilesProperties new) + files: (OrderedCollection with: '${targetPlatform}/vm/sqUnixHeartbeat.c') + propertiesandvalues:{'COMPILE_FLAGS' . cflags}).! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>cogitClass (in category 'source generation') ----- + cogitClass + ^ StackToRegisterMappingCogit + ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>compilerDefinitions (in category 'compiling') ----- + compilerDefinitions + + self deprecated: 'Legacy method from pharo approach. We need different definitions for each buildType'. + + ^#( + '-DNDEBUG' + '-DDEBUGVM=0' + ' -DLSB_FIRST=1' + '-D_GNU_SOURCE' + '-D_FILE_OFFSET_BITS=64' + " '-DUSE_GLOBAL_STRUCT=0'" + '-DCOGMTVM=0') + ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>compilerFlags (in category 'compiling') ----- + compilerFlags + ^#("'-Wall'" + '-w' + '-m32' + '-msse2' + " '-g3' extra debugging info" + '-O1' + " '-fno-caller-saves' + '-fno-tree-pre'") + ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>defaultExternalPlugins (in category 'plugins') ----- + defaultExternalPlugins + "" + ^#()! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>dirBuildLanguageVMMM (in category 'cmake') ----- + dirBuildLanguageVMMM + ^self squeakCogV3! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>dirInstall (in category 'cmake') ----- + dirInstall + "the directory of the finished product.. the place where 'make install' puts stuff. + SystemNavigation default browseMethodsWhoseNamesContain: 'outputDir' + " + ^self squeakCogV3! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>excludeFromBuild (in category 'cmake') ----- + excludeFromBuild + ^false "build this configuration" + " ^true" "do not build this configuration" + + ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>executableName (in category 'cmake') ----- + executableName + ^ self vmCogExecutableName! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>externalLibsBuild (in category 'cmake buildType redirects') ----- + externalLibsBuild + ^self externalLibraries asOrderedCollection. + ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>interpreterClass (in category 'source generation') ----- + interpreterClass + ^ CoInterpreter! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>linkerFlags (in category 'compiling') ----- + linkerFlags + ^#( '-Wl' + '-z' + 'now' + ) + ! Item was changed: Object subclass: #SqueakCMakeVMMakerAbstractBuilder instanceVariableNames: 'buildTypeAndDirectoryInfo config' classVariableNames: '' poolDictionaries: '' category: 'CMakeVMMakerSqueak-Builder'! SqueakCMakeVMMakerAbstractBuilder class instanceVariableNames: 'default'! + !SqueakCMakeVMMakerAbstractBuilder commentStamp: 'tty 2/7/2016 08:51' prior: 0! - !SqueakCMakeVMMakerAbstractBuilder commentStamp: 'tty 12/9/2014 12:41' prior: 0! I am an abstract base class for various CMakeVMMakerSqueak builders. I am a singleton. I am a facade to the various Squeak[Platform][WordSize][VM][MemoryManager]Config classes I provide facilities to query my configurations. I use the Visitor pattern in collecting information about my configurations. + HelpBrowser openOn: CMakeVMMakerSqueakDeveloperHelp. - HelpBrowser openOn: CMakeVMMakerSqueakHelp. + ! SqueakCMakeVMMakerAbstractBuilder class instanceVariableNames: 'default'!

1 0

status report on CMakeVMMakerSqueak
by gettimothy 29 May '16

29 May '16

Just an FYI to keep you updated. 1. Current work is on concurrently developing a Linux32x86 (w 32 bit compat libs) squeak.cog.spur/build Configuration AND the Help documentation to create the thing (Writing the Help is the time consuming stuff, but critical) When that is done, I will test my Help writing, by porting the app to a pure 64x64 machine and duplicating that process for a pure linux 64x64 configuration. That will ensure the Help pages needed by others to create their own Configurations for different platforms are reasonably solid. 2.a some of the Plugins processing currently has some hard-coded stuff from pharo that must be removed. for example configDotCameraPlugin ^'PLUGIN_REQUIRE_INCLUDE(V4L2 linux/videodev2.h /usr/include)' needs rethinking while: configDotClipboardExtendedPlugin ^' IF (NOT X11_FOUND) PLUGIN_DISABLE() ENDIF ()' is reasonable 2.b. Look critically at the Plugin processing...I am thinking wrappers to replace what I currently have. 3. Step back and look at the CMake generation process then refactor such that its methods clearly communicate the methodical process of creating a CMake build tree. Currently it is conceptually cluttered incorporating code from Ian's CMake work and steps from the pharo CMakeVMMaker work. The construction Idiom I am using is directly from Seaside's html component idiom. Constructing a very complicated web-page using Seaside components is conceptually easy ; Constructing complicated CMake files should be too. 4. Decoupling the CMakeVMMakerSqueak from the existing pharo CMakeVMMaker 5. Enlist crowd-sourcing to complete the Configurations for each [Platform][Language.VM.MemoryModel][BuildType] [4 platforms]x [2 languages x 3 vms x 2 memory models] x [6 build types]=eleventy billion configurations (or maybe 288 ) 6. (optional) "Auto" CMake templates creation and by CMake version as such.... parse the output of 'cmake --help-commands and create CMake Templates (classes) from that data. CMake Templates are conceptually the same as Seaside HTML Components . Composing them makes constructing CMakeLists.txt files easy process. 7. (optional) Seaside application that allows a user to select from or create on the fly a CMake build tree for their platform. 8. steal all the underpants. 9.??? 10. profit! cheers. tty

1 0

platforms/unix/vm *.c vs platform and build type
by gettimothy 29 May '16

29 May '16

Does a matrix exist that maps ls -1 Cog/platforms/unix/vm/*.c aio.c debug.c dlfcn-dyld.c mac-alias.c osExports.c sqUnixCharConv.c sqUnixEvent.c sqUnixExternalPrims.c sqUnixHeartbeat.c sqUnixITimerHeartbeat.c sqUnixITimerTickerHeartbeat.c sqUnixMain.c sqUnixMemory.c sqUnixSpurMemory.c sqUnixThreads.c sqUnixVMProfile.c to build type and platform? If not, I will assemble one by hand, but I don't want to duplicate work that has already been done. For example... linux32x86 squeak.cog.v3 builds fine with sqUnixMemory.c however squeak.cog.spur requires sqUnixSpurMemory.c I suspect all the relationships are encoded in the configure and mvm scripts. If they are documented elsewhere, it will save some work. thx

2 2

Crash in directory access on Mac OS X 32-bit
by Eliot Miranda 29 May '16

29 May '16

Process: Squeak [84852] Path: /Users/USER/*/CocoaFast.app/Contents/MacOS/Squeak Identifier: org.squeak.Squeak$(VM_MONIKER) Version: 5.0.3732 (5.0.3732) Code Type: X86 (Native) Parent Process: bash [54145] Responsible: iTerm [980] User ID: 594 Date/Time: 2016-05-28 18:56:04.569 -0700 OS Version: Mac OS X 10.9.5 (13F1808) Report Version: 11 Anonymous UUID: F54BABC9-4764-81AE-0375-EA1A9A4A38C2 Sleep/Wake UUID: 02B5D29D-A0A9-414F-93DC-4EA822100B81 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 VM Regions Near 0: --> __PAGEZERO 0000000000000000-0000000000001000 [ 4K] ---/--- SM=NUL /Users/USER/*/CocoaFast.app/Contents/MacOS/Squeak VM_ALLOCATE 0000000000001000-0000000000026000 [ 148K] ---/--- SM=NUL Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x98f84a80 (anonymous namespace)::AutoreleasePoolPage::autoreleaseSlow(objc_object*) + 412 1 libobjc.A.dylib 0x98f96799 _objc_rootAutorelease2(objc_object*) + 72 2 com.apple.Foundation 0x91bff082 +[NSData(NSData) dataWithBytesNoCopy:length:] + 92 3 com.apple.Foundation 0x91bfefd1 -[NSFileManager fileSystemRepresentationWithPath:] + 431 4 com.apple.Foundation 0x91bfee11 -[NSString(NSPathUtilities) fileSystemRepresentation] + 62 5 com.apple.Foundation 0x91bfeb6e -[NSFileManager directoryContentsAtPath:matchingExtension:options:keepExtension:error:] + 239 6 com.apple.Foundation 0x91bfea73 -[NSFileManager contentsOfDirectoryAtPath:error:] + 71 7 org.squeak.Squeak$(VM_MONIKER) 0x0009b7b0 -[sqSqueakFileDirectoryInterface dir_Lookup:length:index:name:length:creationDate:modificationDate:isDirectory:sizeIfFile:posixPermissions:isSymlink:] + 472 (sqSqueakFileDirectoryInterface.m:215) 8 org.squeak.Squeak$(VM_MONIKER) 0x0009adbe dir_Lookup + 156 (sqSqueakFileDirectoryAPI.m:108) 9 org.squeak.Squeak$(VM_MONIKER) 0x000b8b99 primitiveDirectoryLookup + 257 10 ??? 0x046cacc8 0 + 74230984 11 org.squeak.Squeak$(VM_MONIKER) 0x0002759a interpret + 741 (gcc3x-cointerp.c:2547) 12 org.squeak.Squeak$(VM_MONIKER) 0x0009d7dc -[sqSqueakMainApplication runSqueak] + 476 (sqSqueakMainApplication.m:200) 13 com.apple.Foundation 0x91c5af70 __NSFirePerformWithOrder + 419 14 com.apple.CoreFoundation 0x9822a2be __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30 15 com.apple.CoreFoundation 0x9822a20f __CFRunLoopDoObservers + 399 16 com.apple.CoreFoundation 0x9821b02e __CFRunLoopRun + 974 17 com.apple.CoreFoundation 0x9821a9ea CFRunLoopRunSpecific + 394 18 com.apple.CoreFoundation 0x9821a84b CFRunLoopRunInMode + 123 19 com.apple.HIToolbox 0x95b21b5d RunCurrentEventLoopInMode + 259 20 com.apple.HIToolbox 0x95b21777 ReceiveNextEventCommon + 163 21 com.apple.HIToolbox 0x95b216bd _BlockUntilNextEventMatchingListInModeWithFilter + 92 22 com.apple.AppKit 0x961f7349 _DPSNextEvent + 1602 23 com.apple.AppKit 0x961f6870 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 119 24 com.apple.AppKit 0x961e915c -[NSApplication run] + 727 25 com.apple.AppKit 0x961d1ff8 NSApplicationMain + 1165 26 libdyld.dylib 0x9aacb701 start + 1 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x00000000 ecx: 0x00000000 edx: 0x001bb900 edi: 0xeb801000 esi: 0x98f848f2 ebp: 0xbff36db8 esp: 0xbff36d80 ss: 0x00000023 efl: 0x00010286 eip: 0x98f84a80 cs: 0x0000001b ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f cr2: 0x00000000 This is the current 3732 VM 5.0 5.0.3732 Mac OS X built on May 26 2016 16:37:53 PDT Compiler: 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur VM] CoInterpreter VMMaker.oscog-eem.1872 uuid: 6db6d610-b1a5-4f4d-978d-22c917bdb3e4 May 26 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1860 uuid: 4d58d995-ee0c-4330-9190-adfa038e8f24 May 26 2016 VM: r3732 http://www.squeakvm.org/svn/squeak/branches/Cog Date: 2016-05-26 13:01:37 -0700 Plugins: r3730 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins _,,,^..^,,,_ best, Eliot

1 0

New Cog VMs available
by Eliot Miranda 28 May '16

28 May '16

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3732 CogVM binaries as per VMMaker.oscog-eem.1873/r3732 General: Make primitiveDoPrimitiveWithArgs usable as a mirror primitive, such that no message needs to be sent to the receiver to evaluate a primitive on it. This would make possible Context>>receiver: obj tryPrimitive: idx withArgs: args. Spur: Fix ephemerons (at least for Gule's test case). The mournQueue is of course a root for the scavenger and so must be visited at the start of a scavenge. Fix bug in markAllUnscannedEphemerons, enumerating correctly. Both fireEphemeronsInRememberedSet and fireEphemeronsOnEphemeronList must check for an ephemeron being fireable. An as-yet-firable ephemeron might get added to the ephemeron list and later its key may get tenured, rendering the ephemeron unfirable in that cycle. Fix marking of obj stack contents (markAndTraceObjStack:andContents:). Again tenuring could cause contents to be forwarded and hence read barrier is needed. Fix two bugs in ephemerons (found by Gille Polito - thanks!). 1. obj stack extension must happen with marking set to true if new pages aren't to be GC'ed. So move the assignments to marking out into markObjects: where they can surround nilUnmarkedWeaklingSlots. 2. fireAllUnscannedEphemerons needs to enumerate the unscannedEphemerons set properly, an oop at a time. Fix asserts that check for ephemerons so that the change in an ephemeron's format once it gets added to the mournQueue doesn't break the asserts; isMaybeFiredEphemeron[Format]: answer true for ephemerons and ephemerons in the mournQueue. Fix the Spur implementation of becomeForward:copyHash: for becomming immediates with copyHash false. Fix the scavenger's referenceCountRememberedReferents: for forwarding to immediates, and add a printRememberedSet convenience. Make pushLiteralVariable: store unfollowed literals back into the literal frame. Do so in a function off to the side, not inlined into the interpreter loop. With the above ephemeron changes Guille's test case passes: | e | Smalltalk supportsQueueingFinalization: true. e := (1 to: 200000) collect: [:i| Ephemeron key: (ObjectFinalizer receiver: 'test', 'asd' selector: #logCr) value: Object new]. Smalltalk garbageCollect! Plugins: Simplify the arg validation in FloatArrayPrims>>prmNormalize & primLength. Fix the configuration of the gdb-7.x support for for the GdbARMPlugin (COG=1). Put #if COG around a couple of changes to the gdb-7.10 code. Allow assert to be used in the plugin on MacOS X (-undefined dynamic_lookup) _,,,^..^,,,_ best, Eliot

3 2

Re: [Vm-dev] AioPlugin: VMConstruction-Plugins-AioPlugin-EstebanLorenzano.19.mcz
by Esteban Lorenzano 28 May '16

28 May '16

yeah, but now I saw lots of translations are missing too… so this needs some iterations :( > On 26 May 2016, at 13:56, squeak-dev-noreply(a)lists.squeakfoundation.org wrote: > > > Esteban Lorenzano uploaded a new version of VMConstruction-Plugins-AioPlugin to project AioPlugin: > http://www.squeaksource.com/AioPlugin/VMConstruction-Plugins-AioPlugin-Este… > > ==================== Summary ==================== > > Name: VMConstruction-Plugins-AioPlugin-EstebanLorenzano.19 > Author: EstebanLorenzano > Time: 26 May 2016, 1:56:31.823249 pm > UUID: 6608ce78-afce-4d1b-9061-f24c6492c36c > Ancestors: VMConstruction-Plugins-AioPlugin-eem.18 > > replace cCode: '' with cCode:[] >

3 7

Do we have special bytecode to push class of object or to compare object class?
by Denis Kudriashov 28 May '16

28 May '16

Hi. I want to play with idea to make #ifNil: optimization in the way that for particular receiver it will be always real message send. I want to compile it with extra check like receiver class = MySpecialClass ifTrue: ifNilBlock. I want to measure performance impact. I know in the past #class was compiled as special bytecode. Is it available now? And what bytecode I could use? Best regards, Denis

3 3

Support for reading and writing JPEGs to/from -32, -16, -8 and 8 bit deep forms on V3
by Laura Perez Cerrato 27 May '16

27 May '16

Hello, everyone, During the past few days I've been working on adding support for reading and writing reading and writing JPEGs to/from -32, -16, -8 grayscale and 8 grayscale bit deep forms to JPEGReadWriter2Plugin for the Squeak Cog V3 VM. Just chiming in to tell you that the work is done and I'd like to share it with you all. :) I believe this changes should work on Spur VMs too, but haven't tested thoroughly enough to ensure that. How do you handle contributions to the codebase? I assume I'd have to upload the corresponding changeset to the repository but I'm not sure if there's anything I should do before. I have also been working on a few changes to the latest non-Spur version of Squeak in order to take advantage of the changes to the plugin but, since I added a primitive to it and these changes use it, I think it's prudent to ask you too how those contributions are handled. Should I refer to the Squeak-dev mailing list? Thanks in advance, -Laura Perez Cerrato

4 13

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2016