[Vm-dev] CMakeVMMake compileFlags question for Igor

[Igor Stasenko]

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.html
    "
    ^ {
        '-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 at 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
>

-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140620/2b3cef07/attachment-0001.htm