[Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.106.mcz
commits at source.squeak.org
commits at source.squeak.org
Fri Dec 12 23:50:02 UTC 2014
Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker:
http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.106.mcz
==================== Summary ====================
Name: CMakeVMMakerSqueak-tty.106
Author: tty
Time: 12 December 2014, 6:50:19.922 pm
UUID: b14e94ee-1cdf-4a4d-8a4f-4df3f67a2882
Ancestors: CMakeVMMakerSqueak-tty.105
Continues writing help on creating a new Concrete Configuration. This help depends on an explanation of some design patterns, so I wrote a Help on the design patterns in the code.
Getting closer, hopefully a release of this configuration by Sunday.
=============== Diff against CMakeVMMakerSqueak-tty.105 ===============
Item was added:
+ CMakeVMMakerSqueakDeveloperHelp subclass: #CMakeVMMakerSqueakDesignPatternsHelp
+ instanceVariableNames: ''
+ classVariableNames: ''
+ poolDictionaries: ''
+ category: 'CMakeVMMakerSqueak-Help'!
Item was added:
+ ----- Method: CMakeVMMakerSqueakDesignPatternsHelp class>>bookName (in category 'accessing') -----
+ bookName
+ ^'Design Patterns'!
Item was added:
+ ----- Method: CMakeVMMakerSqueakDesignPatternsHelp class>>key (in category 'accessing') -----
+ key
+ ^'CMakeVMMakerSqueakDesignPatternsHelp'!
Item was added:
+ ----- Method: CMakeVMMakerSqueakDesignPatternsHelp class>>overview (in category 'pages') -----
+ overview
+ ^HelpTopic
+ title: 'Overview'
+ contents:
+ 'CMakeVMMakerSqueak makes heavy use of several design patterns.
+
+ They include:
+
+ Visitor Pattern.
+ Method Redirect Pattern*.
+
+
+ *N.B. tty. It might have a different name, I just named it that for reasons that will be apparent.
+
+ '!
Item was added:
+ ----- Method: CMakeVMMakerSqueakDesignPatternsHelp class>>pages (in category 'pages') -----
+ pages
+ ^#( overview
+ visitorPattern
+ redirectPattern
+ redirectPatternMotivation
+ redirectPatternInvocation
+ redirectPatternImplementation
+ redirectPatternHeirarchy
+ redirectPatternSummary)!
Item was added:
+ ----- Method: CMakeVMMakerSqueakDesignPatternsHelp class>>redirectPattern (in category 'pages') -----
+ redirectPattern
+ ^HelpTopic
+ title: 'Method Redirect Pattern'
+ contents:
+ 'What I call The Method Redirect Pattern* is used extensivelly in CPlatformConfigForSqueak.
+
+ Its use is very consistent and intuitive once the reasoning behind it is grasped and its structure understood.
+
+ I discuss this in five parts:
+
+ Motivation
+ Invocation
+ Implementation
+ Heirarchy
+ Summary
+
+
+ *N.B. tty. It might have a different name, I just named it that for reasons that will be apparent.
+ '!
Item was added:
+ ----- 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 the Abstract Base Class
+ Linux64x86w32BitConfig
+
+ 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: CMakeVMMakerSqueakDesignPatternsHelp class>>redirectPatternImplementation (in category 'pages') -----
+ redirectPatternImplementation
+ ^HelpTopic
+ title: 'Method Redirect Implementation'
+ contents:
+ 'Implementation is very straight forward.
+
+ For ''Release'' type buildTypes the default is to return setGlobalOptionsBuild: aMaker.
+
+ Example:
+ setGlobalOptionsBuildMultiThreaded: aMaker
+ ^self setGlobalOptionsBuild: aMaker
+
+ For "Debug" type buildTypes the default is to return setGlobalOptionsBuild: aMaker
+
+ Example:
+
+ setGlobalOptionsBuildAssertITimerHeartbeat: aMaker
+ ^self setGlobalOptionsBuildDebug: aMaker
+
+
+ Any Configuration in the CPlatformConfigForSqueak heirarchy can override any of these Redirect Methods to provide custom results for any build type at any step in the generate process.
+
+
+
+
+ '!
Item was added:
+ ----- Method: CMakeVMMakerSqueakDesignPatternsHelp class>>redirectPatternInvocation (in category 'pages') -----
+ redirectPatternInvocation
+ ^HelpTopic
+ title: 'Method Redirect Invocation'
+ contents:
+ 'Invocation of the Method Redirect Pattern occurs in CMakeVMGenratorSqueak (and possibly in Plugins, but I forget)
+
+ To provide context, browse CMakeVMGeneratorForSqueak >> generateByTemplate and look at the cascade that starts with
+
+ config
+ setGlobalOptions: self;
+ cmakePrefixPath;
+ cmakeIncludePath;
+ ....
+ By the time the Configuration gets to this point the Configuration has configured itself for a particular build type out of the universe of buildTypes provided by
+ SqueakCMakeVMMakerAbstractBuilder allBuildTypes
+
+ The Configuration then "visits" the CMakeVMGeneratorSqueak and the generator starts sending it the messages in the above cascade.
+
+ Lets look at CPlatformConfigForSqueak >> setGlobalOptions: self
+ since it is first in the cascade.
+
+ CPlatformConfigForSqueak >>
+ setGlobalOptions: aMaker
+ "Route this message send to the message appropriate for my buildType "
+ |d |
+ d:= SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo copy.
+ d
+ at: #build put: [self setGlobalOptionsBuild: aMaker];
+ at: #buildAssert put: [self setGlobalOptionsBuildAssert: aMaker];
+ at: #buildAssertITimerHeartbeat put: [self setGlobalOptionsBuildAssertITimerHeartbeat: aMaker];
+ at:#buildDebug put: [self setGlobalOptionsBuildDebug: aMaker];
+ at: #buildDebugITimerHeartbeat put: [self setGlobalOptionsBuildDebugITimerHeartbeat: aMaker ];
+ at: #buildITimerHeartbeat put: [self setGlobalOptionsBuildITimerHeartbeat: aMaker];
+ at: #buildMultiThreaded put: [self setGlobalOptionsBuildMultiThreaded: aMaker ];
+ at: #buildMultiThreadedAssert put: [self setGlobalOptionsBuildMultiThreadedAssert: aMaker];
+ at: #buildMultiThreadedDebug put: [self setGlobalOptionsBuildMultiThreadedDebug: aMaker ];
+ at: #buildNone put:[self setGlobalOptionsNoBuildType: aMaker].
+ ^(d at: buildType) value
+
+ Here, a copy of an existing Dictionary (used for other purposes elsewhere) is modified to containing blocks to be executed for a particular buildType.
+
+ When the Dictionary is populated with these blocks, the block is executed that corresponds to the configurations current buildType.
+
+ The ^(d at: buildType) value evaluates that block and returns its result.
+
+ So, when I evaluate:
+
+ SqueakLinux64x86w32CompatBuilder
+ configureA: #Linux64x86w32BitSqueakCogV3Config forBuildType:#buildMultiThreadedDebug;
+ generateByTemplate.
+
+ The Linux64x86w32BitSqueakCogV3Config sets its buildType to #buildMultiThreadedDebug.
+ When the CMakeVMGeneratorForSqueak send the message ...
+
+ config
+ setGlobalOptions: self;
+ ...
+
+ The configuration method that actually gets executed is
+ self setGlobalOptionsBuildMultiThreadedDebug: aMaker
+
+
+ Ok, that''s how the invocation works. '!
Item was added:
+ ----- Method: CMakeVMMakerSqueakDesignPatternsHelp class>>redirectPatternMotivation (in category 'pages') -----
+ redirectPatternMotivation
+ ^HelpTopic
+ title: 'Method Redirect Pattern Motivation'
+ contents:
+ 'The motivation for the Redirect Pattern is to reduce the number of concrete configurations by encapsulating every possible build type in one concrete configuration
+
+ If you look at the pharo CMakeVMMaker package, under the CMakeVMMaker-Unix class category, note the existence of StackUnixDebugConfig. It is the "Debug" that is the problem. The pharo team supports two build types: Release and Debug, while the Squeak team supports (currently) 10 build types. The number of Concrete Configurations becomes--in my view--too many.
+
+ Here is the math:
+
+ A configurations [PLATFORM].[Language].[VM].[Memory Manager] [buildType] form expands to:
+ [BSD32x64. | .....| SunOS32x86].[Newspeak | Squeak ].Cog | Stack ].[V3 | Spur] [#build | #build.debug| ...| #buildMultiThreadedDebug]
+
+ which in combination yeilds (as of today)
+
+ [10 platforms] x [2 languages] x [2 VM''s] x [2 Memory Managers] x [10 buildTypes] = 600 concrete configurations.
+
+ By implementing the redirect pattern, the buildType is handled within a single concrete implementation. and math becomes a much more manageable
+
+ [10 platforms] x [2 languages] x [2 VM''s] x [2 Memory Managers] = 60 concrete configurations.
+
+ It is for this reason that I implemented this design pattern.
+
+ An explanation of the naming convention is available by evaluating
+ HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp'!
Item was added:
+ ----- Method: CMakeVMMakerSqueakDesignPatternsHelp class>>redirectPatternSummary (in category 'pages') -----
+ redirectPatternSummary
+ ^HelpTopic
+ title: 'Method Redirect Summary'
+ contents:
+ 'The motivation for the Redirect Pattern is to reduce the number of concrete configurations by encapsulating every possible build type in one concrete configuration. This is accomplished by redirecting sends to a single method to a method appropriate for that build type.
+
+
+ A fair critique is to ask "Why the overkill with all the methods when you only use a subset and it is doubtful that a particular one will need to be over-ridden?"
+
+ The answer is that I find it easier to understand--and I believe easier for newbies to understand--the source code when it is consistently applied.
+
+ Secondly, adding new redirect methods is straighforward boilerplate--just a matter of copy-n-paste-rename.
+
+ Thirdly it reduces brain-cycles when debugging.
+
+
+
+
+
+ I hope this tutorial has made things clear.
+
+ '
+ !
Item was added:
+ ----- Method: CMakeVMMakerSqueakDesignPatternsHelp class>>visitorPattern (in category 'pages') -----
+ visitorPattern
+ ^HelpTopic
+ title: 'Visitor Pattern'
+ contents:
+ 'The Visitor Pattern is used in several places in the CMakeVMMakerSqueak system.
+
+ SqueakCMakeVMMakerAbstractBuilder invokes the Visitor pattern on the CMakeVMakerConfigurationInfo by passing Concrete Builders to its visit: method. In this pattern, Instances of CMakeVMMakerConfigurationInfo are just data buckets used to make coding a bit easier.
+
+ In CMakeVMGeneratorForSqueak and CMakePluginGeneratorForSqueak, the generateByTemplate method''s are a modified version of the Visitor pattern.
+
+
+
+
+ '!
Item was changed:
----- Method: CMakeVMMakerSqueakDeveloperHelp class>>pages (in category 'pages') -----
pages
+ ^#(CMakeVMMakerSqueakHistoryHelp CMakeVMMakerSqueakOverviewHelp CMakeVMMakerSqueakDesignPatternsHelp CMakeVMMakerSqueakConfigurationsHelp CMakeVMMakerSqueakTemplatesHelp CMakeVMMakerSqueakGeneratorsHelp CMakeVMMakerSqueakBuildersHelp configDotCmake looseEnds plugins pthreads templates tests )!
- ^#(CMakeVMMakerSqueakHistoryHelp CMakeVMMakerSqueakOverviewHelp CMakeVMMakerSqueakConfigurationsHelp CMakeVMMakerSqueakTemplatesHelp CMakeVMMakerSqueakGeneratorsHelp CMakeVMMakerSqueakBuildersHelp configDotCmake looseEnds plugins pthreads templates tests )!
Item was changed:
----- Method: CMakeVMMakerSqueakOverviewHelp class>>namingConventions (in category 'pages') -----
namingConventions
^HelpTopic
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].[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.
+
+
'!
Item was added:
+ ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>aNoteOnFoo (in category 'pages') -----
+ aNoteOnFoo
+ ^HelpTopic
+ title:'A Note On FOO'
+ contents:
+ 'Since we have customized plugins, now is a good time to introduce the FOO in [PLATFORM][Language][VM][Memory Manager][BuildType][foo]
+
+ The purpose of FOO is to accomadate personal plugins that ''just work'' for an odd-ball platform or odd set of plugins or some obscure operating system..
+
+ Some examples will suffice to convey the purpose of FOO. (below I encase [FOO] for clarity)
+
+ Linux64x86w32BitSqueakCogV3[WithoutGL]Config
+
+ SqueakBSD32x86[TTYsConfigurationFromHell]Config
+
+ Linux32x86SqueakCogV3[BillyBobVeryOwn]Config
+
+ Linux32x86SqueakCogV3[withoutIA32BOCHSPLugin]Config
+
+ you get the idea.
+
+
+ '!
Item was added:
+ ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>choosePlugins (in category 'pages') -----
+ choosePlugins
+ ^HelpTopic
+ title:'Choose Plugins'
+ contents:
+ '
+
+ '!
Item was added:
+ ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>configureAbstractBaseClass (in category 'pages') -----
+ configureAbstractBaseClass
+ ^HelpTopic
+ title:'Configure Abstract Base Class'
+ contents:
+ 'Abstract Base Classes contain configuration information for a specific platform.
+
+ Let''s start from the top and work are way down. evaluate:
+
+ CPlatformConfigForSqueak browseHierarchy
+
+ CPlatformConfigForSqueak is a fairly involved class, but focusing on the protocol ''cmake directory'' for now, we see a bunch of dirFOO methods.
+
+ selectinng:
+
+ CPlatformConfigForSqueak >>dirLinux32x86
+ ^''cmake.build.linux32x86''
+
+ We see the top-level directory for our new platform specific build.
+
+ The next level down in our hierarchy is SqueakUnixConfig which contains configuration info specific to Unix platforms. An example being:
+
+ SqueakUnixConfig>>platformName
+ ^self unixPlatformName
+
+
+ The next level down is our Abstract Base Class for our specific variant of Unix--specifically Linux32x86Config.
+
+ The methods in this class contain system wide configuratin information for this Platform. On a mature platform tree, this class''s configuration should be rock-solid. However, as of 2014.12.09, the Abstract Base Class has not been configured correctly and I must set it up here.
+
+ Setting it up is not difficult and an existing Abstract Base Class can provide a good starting point. However, a familiarity with the design patterns of the Configurations is helpful (particularly the Redirect Method pattern)
+
+ HelpBrowser openOn: CMakeVMMakerSqueakDesignPatternsHelp
+
+
+
+
+ '!
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.
- The naming convention for Configurations takes the following form:
-
- [Platform][Language][VM][MemoryManager][Foo]Config.
- In 2014.12.09 this resolves too..
-
- [Platform][Newspeak | Squeak][Cog | Sista | Stack][V3 | Spur][Foo]Config.
-
SInce I am creating a Squeak Cog V3 config for the Linux32x86 Platform I choose the name:
Linux32x86SqueakCogV3Config.
+ (For a discussion on naming conventions evaluate:
+ HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp
+ )
+
To create it, I subclass the Abstract Base Class for my Platform like so:
Linux32x86Config subclass: #Linux32x86SqueakCogV3Config
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
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 parent and class category to get:
Linux32x86Config subclass: #Linux32x86SqueakCogV3Config
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
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:
SqueakLinux32x86Builder configurationsCategory
--> ''CMakeVMMakerSqueak-Linux32x86''
SqueakLinux32x86Builder availableBuildConfigurations
--> a SortedCollection(#Linux32x86SqueakCogV3Config) "Here we see our new Configuration is visible to the Builder"
SqueakLinux32x86Builder unAvailableBuildConfigurations
--> a SortedCollection(#Linux32x86Config) "The Abstract Base Class is not available to be built"
SqueakLinux32x86Builder availableBuildTypesFor: #Linux32x86SqueakCogV3Config
--> an OrderedCollection(#build) "The Configuration I copied has one Build Type coded/available."
SqueakLinux32x86Builder sourceDirectoryFor:#Linux32x86SqueakCogV3Config
--> "src" "Where the vm source code is located"
+
+ My new configuration is correctly named and in the correct place.
+
'
!
Item was removed:
- ----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>creatingNamingConfiguration (in category 'pages') -----
- creatingNamingConfiguration
- ^HelpTopic
- title:'Creating and Naming a New Configuration '
- contents:
- 'I want to create a new Squeak, Cog, V3 CMake configuration for a pure 32 bit Slackware 14.1 system.
- All tests pass.
- My target Platform is Linux 32x86.
- My class category is CMakeVMMakerSqueak-Linux32x86
- The super-class of my configuration is Linux32x86Config.
-
-
- In class category CMakeVMMakerSqueak-Linux32x86 the Linux32x86Config funtions as an Abstract Base Class for this platform.
-
- I can identify the Abstract Base Class in several ways
-
- 1. Its at the top. Linux32x86Config is at the top of the Platform''s/Class Category inheritence tree .
- 2. Linux32x86Config is named for the Platform--Linux 32x86.
- 3. Examining Linux32x86Config class initialize we see it assigns #true to the isAbstractBaseClass class instance variable.
- 4. Linux32x86Config isAbstractBaseClass answers ''true''
- Linux32x86Config isAbstractBaseClass
- --> true
-
-
-
- '!
Item was changed:
----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>firstCMakeGeneration (in category 'pages') -----
firstCMakeGeneration
^HelpTopic
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.
- 'While not necessary, 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 the Cog svn tree is located under my Squeak install directory in the folder ''oscogvm".
+ Opening an X-term and navigating there it looks like this:
- Opening an x-term, navigating there it looks like this:
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.""
- And 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.macos32x86
build.macos64x64
build.win32x86
+ cmake.build.linux64x86w32BitCompatibility <-----created by CMakeVMMakerSqueak for the Linux64x86w32BitSqueakCogV3Config
- cmake.build.linux64x86w32BitConfig <-----created by CMakeVMMakerSqueak for the Linux64x86w32BitSqueakCogV3Config
history
image
.....
+ That cmake.build.linux64x86w32BitCompatibility directory was generated by a previous cmake generation for the Linux64X86-32BitCompatibility Platform.
- That cmake.build.linux32_64x86 directory was generated by a previous cmake generation for the Linux32_64
+ Now, I ask the Builder to configure my new configuration for a buildType and output its contents. I do so by evaluating:
- (For a discussin of naming conventions evaluate:
- HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp
+ SqueakLinux32x86Builder
+ configureA: #Linux32x86SqueakCogV3Config forBuildType:#build;
+ enableMessageTracking: true;
+ generateByTemplate.
- )
+ and look again :
+ bash-4.2$ ls cmake.build.linux64x86w32BitCompatibility/
+ squeak.cog.v3
+ 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.
- SqueakLinux32x86Builder
- configureA: #Linux32x86SqueakCogV3Config forBuildType:#build;
- enableMessageTracking: true;
- generateByTemplate.
+ 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.
+
+
+
+ dirBuildPlatform
+ "the directory for the platform. example: build.linux32x86"
+ ^self dirLinux32x86
+
+
+
+
'
!
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.
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.
I suspect that the SqueakLinux32x86Builder as the Builder that will manage my new configuration.
I confirm this by sending it the ''configurationsCategory'' message as shown below:
SqueakLinux32x86Builder configurationsCategory
+ -->''CMakeVMMakerSqueak-Linux32x86'' <---this is the correct class category for my Platform.
- -->''CMakeVMMakerSqueak-Linux32x86''
This is correct Builder for my new Configuration.
I can query the Builder for some more information:
SqueakLinux32x86Builder availableBuildConfigurations
a SortedCollection() <--there are no concrete configurations in place as of this writing.
SqueakLinux32x86Builder unAvailableBuildConfigurations
a SortedCollection(#Linux32x86Config) <--this is my Abstract Base Class. Abstract Base Classes cannot be built, hence they are unavailable.
SqueakLinux32x86Builder buildDirectory
-->''cmake.build.linux32x86'' <--this matches my platform
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 Linux 32 bit x86.
+ I identify my Platform in the existing CMakeVMMakerSqueak-xyz class categories.
- I identify my Platform in the list of 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.
+
+ (For a discussion on naming conventions evaluate:
+ HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp
+ )
+
+
'!
Item was changed:
----- Method: CMakeVMMakerSqueakStepByStepNewConfigurationHelp class>>overview (in category 'pages') -----
overview
^HelpTopic
title:'Overview'
contents:
+ 'This Help Topic is a running commentary on how I created Squeak, Cog, V3 CMake configuration for a pure 32 bit Slackware 14.1 system.
- 'I want to create a new Squeak, Cog, V3 CMake configuration for a pure 32 bit Slackware 14.1 system.
- This Help Topic is a running commentary on accomplishing this task.
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
+ setOutputPath
- "setting paths"
settingPlugins
+ aNoteOnFoo
-
)!
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 must inform Builders what BuildTypes they support.*
Here is my Builder asking my new Configuration what build types it supports (remember, this Configuration was copied, so it has been configured already)
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.
Linux32x86Config>>availableBuildTypes
^SqueakCMakeVMMakerAbstractBuilder default allBuildTypes
Evaluating the return gives us:
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:
Linux32x86SqueakCogV3Config >> availableBuildTypes
^SqueakCMakeVMMakerAbstractBuilder default allBuildTypes copyWithoutAll: #( #buildAssert #buildAssertITimerHeartbeat #buildDebug #buildDebugITimerHeartbeat #buildITimerHeartbeat #buildMultiThreaded #buildMultiThreadedAssert #buildMultiThreadedDebug #buildNone)
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:
- With the result that my Builder shows the removed items:
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. 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>>setOutputPath (in category 'pages') -----
+ setOutputPath
+ ^HelpTopic
+ title:'Set Output Path'
+ contents:
+ 'WRITE ME
+
+ '!
Item was added:
+ ----- Method: CPlatformConfigForSqueak>>dirLinux64x86w32BitCompatibility (in category 'cmake directory ') -----
+ dirLinux64x86w32BitCompatibility
+ ^'cmake.build.linux64x86w32BitCompatibility'!
Item was removed:
- ----- Method: CPlatformConfigForSqueak>>dirLinux64x86w32BitConfig (in category 'cmake directory ') -----
- dirLinux64x86w32BitConfig
- ^'cmake.build.linux64x86w32BitConfig'!
Item was removed:
- ----- Method: Linux32x86Config class>>initialize (in category 'as yet unclassified') -----
- initialize
- isAbstractBaseClass:=true!
Item was changed:
----- Method: Linux32x86Config>>addVMPluginsBuild: (in category 'cmake buildType redirects') -----
addVMPluginsBuild: aMaker
+ |temp o|
+ self flag:'tty'. "I am writing sub-directory CMakeLists.txt here. Should I also write the config.cmake files?"
+ enabledebugmessages
+ ifTrue: [templates "this message will go to the top level CMakeLists.txt file"
+ addLast: (CMakeMessage new message: self class name , 'addVMPluginsBuild: aMaker')].
+ vmplugins do:[ :vmp |
+ o := String new writeStream. "each VMPlugin gets its own CMakeLists.txt file in its own directory"
+ temp := OrderedCollection new.
+ temp
+ addAllLast:((CMakePluginVm new) "this is the CMakeCompositTemplate"
+ config: self
+ definitions: (vmp compilerdefinitions)
+ module: (vmp module)
+ sources: (vmp sources)
+ includedirectories: (vmp includedirectories)).
+ temp do: [:each | o nextPutAll: (each content); cr].
+ ((self buildDir) directoryExists: (vmp module))
+ ifFalse:[ (self buildDir) createDirectory: (vmp module)].
+ self write: (o contents) toFile: vmp module , FileDirectory slash , aMaker outputFileName.
+ templates "this will go to the top level CMakeLists.txt file"
+ addLast: ((CMakeAddSubDirectory new) sourcedir: (vmp module))
+ ].
- aMaker message: 'addVMDrivers: aMaker'.
- self
- addDriver: 'vm-display-null'
- sources: #(
- '${targetPlatform}/vm-display-null/sqUnixDisplayNull' )
- generator: aMaker
- externalLibs: #();
-
- addDriver: 'vm-display-X11'
- sources: #(
- '${targetPlatform}/vm-display-X11/sqUnixX11'
- '${targetPlatform}/vm-display-X11/sqUnixMozilla' )
- generator: aMaker
- externalLibs: (self externalLibs);
- addDriver: 'vm-sound-ALSA'
- sources: #(
- '${targetPlatform}/vm-sound-ALSA/sqUnixSoundALSA' )
- generator: aMaker
- externalLibs: #();
+
+
+
+
+
+
+
- addDriver: 'vm-sound-null'
- sources: #(
- '${targetPlatform}/vm-sound-null/sqUnixSoundNull' )
- generator: aMaker
- externalLibs: #().
!
Item was added:
+ ----- Method: Linux32x86Config>>customizeCMakeVMDisplayNull (in category 'plugins') -----
+ customizeCMakeVMDisplayNull
+ |module|
+ module := vmplugins detect: [:vmd | #CMakeVMDisplayNull = ((vmd class name) asSymbol)] ifNone:[nil]. "error handling?"
+ module
+ sources: #('${targetPlatform}/vm-display-null/sqUnixDisplayNull') ;
+ compilerdefinitions:(OrderedCollection with: '-fPIC' with: '-DPIC');
+ compilerflags: (self compilerFlags);
+ externallibraries: #();
+ linkerflags: (self linkerFlags);
+ includedirectories:(OrderedCollection
+ with:'${crossDir}/plugins/FilePlugin'
+ with: '${targetPlatform}/plugins/B3DAcceleratorPlugin'
+ with: '${crossDir}/plugins/B3DAcceleratorPlugin').
+ self flag:'tty'. "I don't think includedirectories is correct. revisit"
+
+ !
Item was added:
+ ----- Method: Linux32x86Config>>customizeCMakeVMDisplayX11 (in category 'plugins') -----
+ customizeCMakeVMDisplayX11
+ |module|
+ module := vmplugins detect: [:vmd | #CMakeVMDisplayX11 = ((vmd class name) asSymbol)] ifNone:[nil]. "error handling?"
+ module
+ sources: #( '${targetPlatform}/vm-display-X11/sqUnixX11' '${targetPlatform}/vm-display-X11/sqUnixMozilla' );
+ compilerdefinitions:(OrderedCollection with: '-fPIC' with: '-DPIC');
+ compilerflags: (self compilerFlags);
+ externallibraries: (self externalLibraries);
+ linkerflags: (self linkerFlags);
+ includedirectories:(OrderedCollection
+ with:'${crossDir}/plugins/FilePlugin'
+ with: '${targetPlatform}/plugins/B3DAcceleratorPlugin'
+ with: '${crossDir}/plugins/B3DAcceleratorPlugin').
+ !
Item was added:
+ ----- Method: Linux32x86Config>>customizeCMakeVMSoundALSA (in category 'plugins') -----
+ customizeCMakeVMSoundALSA
+ |module|
+ module := vmplugins detect: [:vmd | #CMakeVMSoundALSA = ((vmd class name) asSymbol)] ifNone:[nil]. "error handling?"
+ module
+ sources: #( '${targetPlatform}/vm-sound-ALSA/sqUnixSoundALSA' );
+ compilerdefinitions:(OrderedCollection with: '-fPIC' with: '-DPIC');
+ compilerflags: (self compilerFlags);
+ externallibraries: (self externalLibraries);
+ linkerflags: (self linkerFlags);
+ includedirectories: #().
+ !
Item was added:
+ ----- Method: Linux32x86Config>>customizeCMakeVMSoundNull (in category 'plugins') -----
+ customizeCMakeVMSoundNull
+ |module|
+ module := vmplugins detect: [:vmd | #CMakeVMSoundNull = ((vmd class name) asSymbol)] ifNone:[nil]. "error handling?"
+ module
+ sources: #( '${targetPlatform}/vm-sound-null/sqUnixSoundNull' );
+ compilerdefinitions:(OrderedCollection with: '-fPIC' with: '-DPIC');
+ compilerflags: (self compilerFlags);
+ externallibraries: (self externalLibraries);
+ linkerflags: (self linkerFlags);
+ includedirectories:#()
+
+ !
Item was changed:
----- Method: Linux32x86Config>>customizeVMPlugins (in category 'plugins') -----
customizeVMPlugins
|mysubset iwantonly|
"trim the vmdrivers ordered collection of CMakeVMDriver subclasses to only those I want. then customize them for use on this OS/platform"
+ iwantonly := #(#CMakeVMDisplayNull #CMakeVMDisplayX11 #CMakeVMSoundALSA #CMakeVMSoundNull ).
- " iwantonly := #(#CMakeVMDisplayNull #CMakeVMDisplayX11 #CMakeVMSoundALSA #CMakeVMSoundNull ).
mysubset := vmplugins select: [:vmd | 0 < (iwantonly occurrencesOf: (vmd class name) asSymbol)].
vmplugins := mysubset.
self
customizeCMakeVMDisplayNull;
customizeCMakeVMDisplayX11;
customizeCMakeVMSoundALSA;
+ customizeCMakeVMSoundNull.
+
+
+ !
- customizeCMakeVMSoundNull."!
Item was changed:
+ Linux32x86Config subclass: #Linux32x86SqueakCogV3Config
- Linux64x86w32BitConfig subclass: #Linux32x86SqueakCogV3Config
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'CMakeVMMakerSqueak-Linux32x86'!
!Linux32x86SqueakCogV3Config 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 removed:
- ----- Method: Linux64x86w32BitConfig class>>licenseTemplate (in category 'accessing') -----
- licenseTemplate
- ^'Squeak {1} license information
- ==============================
-
- About Squeak
- -----------
- Squeak is a modern, open source, full-featured implementation of the powerful Smalltalk programming language and environment. Squeak is highly-portable, running on almost any platform you could name and you can really truly write once run anywhere. Squeak is the vehicle for a wide range of projects from multimedia applications and educational platforms to commercial web application development.
-
- LIcense
- Note: The current release of Squeak is a combination of source code originating from it''s origins at Apple which Apple agreed to license under the Apache license and more recent contributions licensed under the MIT license. The vast majority of the code is under the MIT license.
- MIT License
-
- Copyright (c) The individual, corporate, and institutional contributors who have collectively contributed elements to this software ("The Squeak Community"), 1996-2010 All rights reserved.
-
- Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
-
- The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
-
- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
- Portions of Squeak are covered by the following license:
- Apache License, Version 2.0
-
- Copyright (c) Xerox Corp. 1981, 1982 All rights reserved. Copyright (c) Apple Computer, Inc. 1985-1996 All rights reserved.
-
- Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
-
-
- About Cog
- ---------
-
- Cog is a virtual machine designed for Smalltalk and other similar dynamic languages. Cog builds on the
- Squeak virtual machine adding a stack-to-register-mapping just-in-time compiler, aggressive in-line message
- cacheing and effective optimization of Smalltalk?s first-class activation records. Cog is the virtual machine
- underlying Teleplace''s Croquet-based enterprise virtual collaboration spaces software, the fastest virtual
- machine for Squeak, and for Gilad Bracha''s Newspeak modular language inspired by Beta and Smalltalk.
- Like the original Squeak VM, Cog is implemented and developed in Smalltalk, and translated into a lower-level
- language to produce the production VM. Being a Smalltalk program it is a delight to develop. Cog is
- available under the MIT open source license and is unencumbered for commercial deployment.
-
- Cog''s performance relative to the existing Squeak interpreter varies, depending on the benchmark chosen.
- As of early-2011, the Cog JIT uses strong inline cacheing techniques and stack-to-register mapping that
- results in a register-based calling convention for low-arity methods. Due to the complexity of the Squeak
- object representation it has a limited set of primitives implemented in machine code that, for example,
- exclude object allocation. Performance of the early-2011 JIT for the nbody, binarytrees and chameneos
- redux benchmarks from the computer language shootout is in the range of 4 to 6 times faster than the
- interpreter.
- '!
Item was removed:
- ----- Method: Linux64x86w32BitConfig class>>pluginsTemplate (in category 'accessing') -----
- pluginsTemplate
- ^'{4} {1} ships with this plugins already built:
-
- Internal:
- =========
- {2}
-
- External:
- =========
- {3}
-
- '!
Item was changed:
----- Method: Linux64x86w32BitConfig>>defaultExternalPlugins (in category 'plugins') -----
defaultExternalPlugins
+ ^ #(
+ B3DAcceleratorPlugin
+ ThreadedIA32FFIPlugin "SqueakFFIPrims"
+ "UUIDPlugin"
+ "UnixOSProcessPlugin ?? "
+ JPEGReaderPlugin
+ JPEGReadWriter2Plugin
+ RePlugin
+ InternetConfigPlugin
+ )
+
+ "debug"!
- "developing template model for plugins one at a time"
- ^ #()
- !
Item was changed:
----- Method: Linux64x86w32BitConfig>>dirBuildPlatform (in category 'cmake') -----
dirBuildPlatform
+ ^self dirLinux64x86w32BitCompatibility!
- "the directory for the platform. example: build.linux32x86"
- ^self dirLinux64x86w32BitConfig!
More information about the Vm-dev
mailing list