[Vm-dev] CMakeVMMake compileFlags question for Igor
gettimothy
gettimothy at zoho.com
Thu Jun 19 16:22:42 UTC 2014
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140619/b69cf9aa/attachment.htm
More information about the Vm-dev
mailing list