[Vm-dev] CMakeVMMake compileFlags question for Igor

[gettimothy]

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