Hi Igor (and all)
My goal is to develop a documented, boilerplate, easily duplicated, correct procedure for adding or modifying a CMakeVMaker(Squeak) configuration whenever Eliot adds or modifies a configuration in the GNU tree.
Using build.linux32x86/squeak.cog.v3/ as an example, I want to be able to examine the 'mvm' files in each build directory:
build build.assert build.assert.itimerheartbeat build.debug build.debug.itimerheartbeat build.itimerheartbeat build.multithreaded build.multithreaded.assert build.multithreaded.debug
And accurately translate that information into the appropriate CMakeVMaker(Squeak) Configuration class.
Using build.linux32x86/squeak.cog.v3/build/mvm as the example, we see that GNU system has this in their setup:
test -f config.h || ../../../platforms/unix/config/configure --without-npsqueak \ 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
The reason for this email is that I want to verify/clarify that my approach is correct and to share my concerns.
Please correct me or clarify as I go.
So line-by-line....
test -f config.h || ../../../platforms/unix/config/configure --without-npsqueak \ We are hard-coding this (for now) in configH method.
(Incidently, David. I looked at Ian's code briefly a couple of nights ago and he as a config.cmake step that is run. Much of Ian's code looks very similar to what is happening in VMakeCMake(Squeak). Once release 1 of this puppy is up, I will hopefully know enought to integrate Ian's work)
CC="gcc -m32" \ CXX="g++ -m32" \
I "think" these are handled in
setGlobalOptions: maker
"set any CMake global options, before declaring a project in cmake file"
maker set: 'CMAKE_C_COMPILER' to: '/usr/bin/gcc'. maker set: 'CMAKE_CXX_COMPILER' to: '/usr/bin/g++'. But I am not sure where to pass in the '-m32' flag. I will research this on Google, but if you know, it would be much appreciated.
CFLAGS="$OPT -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DCOGMTVM=0" \
I trust these are handled in CMakeVMaker(Squeak)
compilerFlags ^ { '-O0'. '--msse2'. '-D_GNU_SOURCE'. '-D_FILE_OFFSET_BITS=64'. '-DCOGMTVM=0'. }
Should I just throw the '-m32' in here? remember, my goal is to be boilerplate consistent going forward.
Now things get a bit confusing....
IN GNU we have LIBS="-lpthread -luuid" \ is represented by CMakeVMMaker(Squeak)
linkFlags ^ '-lSM -lICE -ldl -lGL -lpthread -lm -lnsl -lX11'
From google, "-L is the path to the directories containing the libraries. A search path for libraries." and "-l is the name of the library you want to link to."
so the heuristics of the name is "libraries to link to" and not "linker flags".
Finally we have linker flags:
LDFLAGS=-Wl,-z,now
We don't have a method for this, except that setExtraTargetProperties seems to be a catch-all method.... Here are a couple examples at random:
setExtraTargetProperties: maker
maker setTargetProperties: 'LINK_FLAGS "-m32"'.
maker puts: 'set_source_files_properties( ${srcVMDir}/cogit.c PROPERTIES COMPILE_FLAGS "-O1 -fno-omit-frame-pointer -momit-leaf-frame-pointer -mno-rtd -mno-accumulate-outgoing-args")'.
maker cmd: 'set_source_files_properties' params: ' ${targetPlatform}/vm/sqUnixHeartbeat.c PROPERTIES COMPILE_FLAGS "-O1 -fno-omit-frame-pointer -mno-rtd -mno-accumulate-outgoing-args"'.
super setExtraTargetProperties: maker.
or in another class:
maker addExternalLibraries: #( 'm' "math lib" 'dl' "dynamic loader" 'pthread' "posix threads" ).
maker set: 'EXECUTABLE_OUTPUT_PATH' toString: self outputDir fullName. self addVMDrivers: maker.
In summary, here is what I am thinking.
I. research the CC and CXX '-m32' and if CMake doesn't handle it make sure putting it in compilerFlags is ok. 2. CFlags=compilerFlags 3. LIBS= (I think this needs to be refactored with the method renamed in an override) 4. LDFlags (I think we need a new method for these in CMakeVMGenerator>generate method)
Anyway, I wanted to get your input before proceeding. To re-iterate. I am in "boilerplate" coding mode now where I want to take an existing GNU build and create a documented, boilerplate, consistent method of porting existing GNU builds.
Cheers.
tty
p.s. for ease of reference the CMakeVMGenrator>generate method is produced below:
generate | intPlugins extPlugins |
output := String new writeStream. config setGlobalOptions: self.
self printHeader; project: config executableName.
config setGlobalOptionsAfterDetermineSystem: self.
config setupDirectories: self.
self message: '${CMAKE_MODULE_PATH}'. self set: 'CMAKE_CONFIGURATION_TYPES' to: 'Release'.
config preferredIncludes do: [ :each | self includeDirectories: each ]. self includeDirectories: self includeDirs. config standardIncludes do: [:each | self includeDirectories: each ].
self addDefinitions: config compilerFlags.
config extraVMSettings: self.
self puts: 'add_executable(' , config executableName, ' ', config executableType, ' ' , self sources , ')'.
intPlugins := self generatePluginConfigs: config internalPlugins internal: true. extPlugins := self generatePluginConfigs: config externalPlugins internal: false.
self processThirdpartyLibraries.
self processPlugins: intPlugins, extPlugins.
config setExtraTargetProperties: self.
self cmd: 'target_link_libraries' params: self moduleName , ' ${LINKLIBS}'.
config postBuildActions: self.
self saveFile. self generateBuildScript.
yes, it should be in compilerFlags/ linkerFlags
compilerFlags | releaseFlags |
releaseFlags := self isGenerateForRelease ifTrue: [ self compilerFlagsRelease ] ifFalse: [ self compilerFlagsDebug ].
^ String streamContents: [ :stream | ((self commonCompilerFlags, releaseFlags) collect: #trimBoth as: Set) asStringOn: stream delimiter: ' ' ]
CocoaIOSConfig>>commonCompilerFlags "Common compiler flags" ^{ '-arch i386'. '-mmacosx-version-min=10.5'. '-DHAVE_UUID_GENERATE'. '-DDEFAULT_IMAGE_NAME="', self executableName, '.image"'}
CogUnixConfig>>commonCompilerFlags
"Common compiler flags
LSB_FIRST=1 means that target platform is little endian. set it to 0 for big-endian platforms
"
^ { '-DLSB_FIRST=1'. '-DUSE_GLOBAL_STRUCT=0'. '-DCOGMTVM=0'. '-m32'. '-DENABLE_FAST_BLT ' }
CogFamilyWindowsConfig>>commonCompilerFlags "omit -ggdb2 to prevent generating debug info" "Some flags explanation:
STACK_ALIGN_BYTES=16 is needed in mingw and FFI (and I suppose on other modules too). DALLOCA_LIES_SO_USE_GETSP=0 Some compilers return the stack address+4 on alloca function, then FFI module needs to adjust that. It is NOT the case of mingw. For more information see this thread: http://forum.world.st/There-are-something-fishy-with-FFI-plugin-td4584226.ht... " ^ { '-march=pentium4'. '-mwindows'. '-D_MT'. '-msse2'. '-mthreads'. '-mwin32'. '-mno-rtd'. '-mms-bitfields'. '-mno-accumulate-outgoing-args ', self winVer. '-DWIN32'. '-DWIN32_FILE_SUPPORT'. '-DNO_ISNAN'. '-DNO_SERVICE'. '-DNO_STD_FILE_SUPPORT'. '-DLSB_FIRST'. '-DVM_NAME="', self executableName,'"'. '-DX86 '. '-DSTACK_ALIGN_BYTES=16'. '-DALLOCA_LIES_SO_USE_GETSP=0'. '-DENABLE_FAST_BLT ' }
On 19 June 2014 18:22, gettimothy gettimothy@zoho.com wrote:
Hi Igor (and all)
My goal is to develop a documented, boilerplate, easily duplicated, correct procedure for adding or modifying a CMakeVMaker(Squeak) configuration whenever Eliot adds or modifies a configuration in the GNU tree.
Using build.linux32x86/squeak.cog.v3/ as an example, I want to be able to examine the 'mvm' files in each build directory:
build build.assert build.assert.itimerheartbeat build.debug build.debug.itimerheartbeat build.itimerheartbeat build.multithreaded build.multithreaded.assert build.multithreaded.debug
And accurately translate that information into the appropriate CMakeVMaker(Squeak) Configuration class.
Using build.linux32x86/squeak.cog.v3/build/mvm as the example, we see that GNU system has this in their setup:
test -f config.h || ../../../platforms/unix/config/configure --without-npsqueak \ 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
The reason for this email is that I want to verify/clarify that my approach is correct and to share my concerns.
Please correct me or clarify as I go.
So line-by-line....
test -f config.h || ../../../platforms/unix/config/configure --without-npsqueak \
- We are hard-coding this (for now) in configH method. *
(Incidently, David. I looked at Ian's code briefly a couple of nights ago and he as a config.cmake step that is run. Much of Ian's code looks very similar to what is happening in VMakeCMake(Squeak). Once release 1 of this puppy is up, I will hopefully know enought to integrate Ian's work)
CC="gcc -m32" \ CXX="g++ -m32" \
I "think" these are handled in
setGlobalOptions: maker
"set any CMake global options, before declaring a project in cmake
file"
maker set: 'CMAKE_C_COMPILER' to: '/usr/bin/gcc'. maker set: 'CMAKE_CXX_COMPILER' to: '/usr/bin/g++'.
- But I am not sure where to pass in the '-m32' flag. *I will research
this on Google, but if you know, it would be much appreciated.
CFLAGS="$OPT -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-DCOGMTVM=0" \
I trust these are handled in CMakeVMaker(Squeak)
compilerFlags ^ { '-O0'. '--msse2'. '-D_GNU_SOURCE'. '-D_FILE_OFFSET_BITS=64'. '-DCOGMTVM=0'. }
*Should I just throw the '-m32' in here? remember, my goal is to be boilerplate consistent going forward.*
Now things get a bit confusing....
IN GNU we have
LIBS="-lpthread -luuid" \
is represented by CMakeVMMaker(Squeak)
linkFlags ^ '-lSM -lICE -ldl -lGL -lpthread -lm -lnsl -lX11'
here it is:
CogUnixConfig>>linkFlags ^ super linkFlags , ' -m32'
From google, "-L is the path to the directories containing the libraries. A search path for libraries." and "-l is the name of the library you want to link to." *so the heuristics of the name is "libraries to link to" and not "linker flags".*
Finally we have linker flags:
LDFLAGS=-Wl,-z,now
We don't have a method for this, except that setExtraTargetProperties seems to be a catch-all method.... Here are a couple examples at random:
setExtraTargetProperties: maker
maker setTargetProperties: 'LINK_FLAGS "-m32"'. maker puts: 'set_source_files_properties( ${srcVMDir}/cogit.c
PROPERTIES COMPILE_FLAGS "-O1 -fno-omit-frame-pointer -momit-leaf-frame-pointer -mno-rtd -mno-accumulate-outgoing-args")'.
maker cmd: 'set_source_files_properties' params: ' ${targetPlatform}/vm/sqUnixHeartbeat.c PROPERTIES COMPILE_FLAGS "-O1 -fno-omit-frame-pointer -mno-rtd
-mno-accumulate-outgoing-args"'.
super setExtraTargetProperties: maker.
or in another class:
maker addExternalLibraries: #( 'm' "math lib" 'dl' "dynamic loader" 'pthread' "posix threads" ). maker set: 'EXECUTABLE_OUTPUT_PATH' toString: self outputDir fullName. self addVMDrivers: maker.
In summary, here is what I am thinking.
I. research the CC and CXX '-m32' and if CMake doesn't handle it make sure putting it in compilerFlags is ok. 2. CFlags=compilerFlags 3. LIBS= (I think this needs to be refactored with the method renamed in an override) 4. LDFlags (I think we need a new method for these in CMakeVMGenerator>generate method)
Anyway, I wanted to get your input before proceeding. To re-iterate. I am in "boilerplate" coding mode now where I want to take an existing GNU build and create a documented, boilerplate, consistent method of porting existing GNU builds.
Note that different parts of configs was filled at different times, by different people. So, no surprise, things are a bit messy. Feel free to put a better order and place things into more appropriate place and properly comment/document them (as long as build will keep working, of course :).
Cheers.
tty
Hi Igor.
Thank you. What you say makes perfect sense.
I now have the confidence to proceed.
CMakeVMmakerSqueak as a subclass of CMakeVMGenerator that handles the Pharo-to-Squeak compatibility issues.
I will override the generate method in there and introduce a couple of methods that mirror the 'mvm' layout. It will probably end up funneling a most of its stuff into compilerFlags, but my focus is on the end-user and 'boilerplate' procedures for the newbie.
If the pharo team finds it useful, it can be pushed up to the superclass.
cheers,
tty
On 20 June 2014 14:10, gettimothy gettimothy@zoho.com wrote:
Hi Igor.
Thank you. What you say makes perfect sense.
I now have the confidence to proceed.
CMakeVMmakerSqueak as a subclass of CMakeVMGenerator that handles the Pharo-to-Squeak compatibility issues. I will override the generate method in there and introduce a couple of methods that mirror the 'mvm' layout. It will probably end up funneling a most of its stuff into compilerFlags, but my focus is on the end-user and 'boilerplate' procedures for the newbie.
If the pharo team finds it useful, it can be pushed up to the superclass.
i would prefer if you do it cleanly, without need more work later. As you may know, CMakeVMMaker are part of pharo-vm and hosted on github https://github.com/pharo-project/pharo-vm so, if you want to contribute, you can do it in a usual way how all guthub-hosted projects doing: make own clone and then do a pull request. The older locations of CMakeVMMaker is no longer maintained by our team.
cheers,
tty
vm-dev@lists.squeakfoundation.org