Separate compile flags for ASM/C compilers and lists

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Separate compile flags for ASM/C compilers and lists

lorddoskias
Hello list,

I have a couple of questions whose answers I couldn't find. So first thing's first - I have the following function which I intend to use to add a number of library targets:

function(build_mps_m3_lib LIBRARY_NAME C_SOURCE ASM_SOURCE CPU_TYPE)
    set_property(SOURCE ${${C_SOURCE}} PROPERTY COMPILE_FLAGS "-g --cpu=${CPU_TYPE} -O0")
    set_property(SOURCE ${${ASM_SOURCE}} PROPERTY COMPILE_FLAGS "-g --cpu=${CPU_TYPE} --apcs=interwork")
    add_library(${LIBRARY_NAME}  ${${SOURCE}} ${${ASM_SOURCE}})
    set(TARGET_DIR "mps-m3")
    set(ASM_COMPILE_FLAGS "-g --cpu=${CPU_TYPE} --apcs=interwork")
    #custom armasm command line
    set(CMAKE_ASM_COMPILE_OBJECT "<CMAKE_ASM_COMPILER> ${ASM_COMPILE_FLAGS} <SOURCE> -o <OBJECT>")
    #set_target_properties(${LIBRARY_NAME} PROPERTIES C_COMPILE_FLAGS "-g --cpu=${CPU_TYPE} -O0")
 
endfunction(build_mps_m3_lib)


What I want to achieve is to have clear separation between the ASM compiler flags and the C compiler flags. Since I'm not using the GNU (ergo GCC) toolchain I cannot simply set the properties on the resulting library target to set the COMPILE_FLAGS. Essentially what I want to achieve is being able to set arbitrary compile options for the C and ASM compiler WITHOUT both of those interfering.

My second questions: The way I pass the lists of sources is kind of ugly - e.g. I'm, in-essence, doing double indirection the ${${blah}} thingy. What would be the correct way. I tried with ${blah-list} but this skewed the arguments order


Regards

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Separate compile flags for ASM/C compilers and lists

Alexander Neundorf-3
On Friday 13 September 2013, lorddoskias wrote:

> Hello list,
>
> I have a couple of questions whose answers I couldn't find. So first
> thing's first - I have the following function which I intend to use to
> add a number of library targets:
>
> function(build_mps_m3_lib LIBRARY_NAME C_SOURCE ASM_SOURCE CPU_TYPE)
>      set_property(SOURCE ${${C_SOURCE}} PROPERTY COMPILE_FLAGS "-g
> --cpu=${CPU_TYPE} -O0")
>      set_property(SOURCE ${${ASM_SOURCE}} PROPERTY COMPILE_FLAGS "-g
> --cpu=${CPU_TYPE} --apcs=interwork")
>      add_library(${LIBRARY_NAME}  ${${SOURCE}} ${${ASM_SOURCE}})
>      set(TARGET_DIR "mps-m3")
>      set(ASM_COMPILE_FLAGS "-g --cpu=${CPU_TYPE} --apcs=interwork")
>      #custom armasm command line
>      set(CMAKE_ASM_COMPILE_OBJECT "<CMAKE_ASM_COMPILER>
> ${ASM_COMPILE_FLAGS} <SOURCE> -o <OBJECT>")
>      #set_target_properties(${LIBRARY_NAME} PROPERTIES C_COMPILE_FLAGS
> "-g --cpu=${CPU_TYPE} -O0")
> endfunction(build_mps_m3_lib)
>
>
> What I want to achieve is to have clear separation between the ASM
> compiler flags and the C compiler flags. Since I'm not using the GNU
> (ergo GCC) toolchain I cannot simply set the properties on the resulting
> library target to set the COMPILE_FLAGS. Essentially what I want to
> achieve is being able to set arbitrary compile options for the C and ASM
> compiler WITHOUT both of those interfering.

In general they don't interfer.
What compiler and assembler are you using ?
Maybe you need a new "assembler dialect". Those are quite simply to do, you
can have a look e.g. at the files containing "MASM" in their name in Modules/.
 
> My second questions: The way I pass the lists of sources is kind of ugly
> - e.g. I'm, in-essence, doing double indirection the ${${blah}} thingy.
> What would be the correct way. I tried with ${blah-list} but this skewed
> the arguments order

To get full support for keywords etc. in your own macros/functions, have a
look at CMakeParseArguments.cmake.

Alex
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Separate compile flags for ASM/C compilers and lists

lorddoskias



On 14 September 2013 09:59, Alexander Neundorf <[hidden email]> wrote:
On Friday 13 September 2013, lorddoskias wrote:
> Hello list,
>
> I have a couple of questions whose answers I couldn't find. So first
> thing's first - I have the following function which I intend to use to
> add a number of library targets:
>
> function(build_mps_m3_lib LIBRARY_NAME C_SOURCE ASM_SOURCE CPU_TYPE)
>      set_property(SOURCE ${${C_SOURCE}} PROPERTY COMPILE_FLAGS "-g
> --cpu=${CPU_TYPE} -O0")
>      set_property(SOURCE ${${ASM_SOURCE}} PROPERTY COMPILE_FLAGS "-g
> --cpu=${CPU_TYPE} --apcs=interwork")
>      add_library(${LIBRARY_NAME}  ${${SOURCE}} ${${ASM_SOURCE}})
>      set(TARGET_DIR "mps-m3")
>      set(ASM_COMPILE_FLAGS "-g --cpu=${CPU_TYPE} --apcs=interwork")
>      #custom armasm command line
>      set(CMAKE_ASM_COMPILE_OBJECT "<CMAKE_ASM_COMPILER>
> ${ASM_COMPILE_FLAGS} <SOURCE> -o <OBJECT>")
>      #set_target_properties(${LIBRARY_NAME} PROPERTIES C_COMPILE_FLAGS
> "-g --cpu=${CPU_TYPE} -O0")
> endfunction(build_mps_m3_lib)
>
>
> What I want to achieve is to have clear separation between the ASM
> compiler flags and the C compiler flags. Since I'm not using the GNU
> (ergo GCC) toolchain I cannot simply set the properties on the resulting
> library target to set the COMPILE_FLAGS. Essentially what I want to
> achieve is being able to set arbitrary compile options for the C and ASM
> compiler WITHOUT both of those interfering.

In general they don't interfer.
What compiler and assembler are you using ?
Maybe you need a new "assembler dialect". Those are quite simply to do, you
can have a look e.g. at the files containing "MASM" in their name in Modules/.

Unfortunately I do not find the statement "In generla they don't interfere to be correct". Here is what I'm talking about:

The default definitions of ASM_COMPILE_OBJECT is : ASM_COMPILE_OBJECTP: <CMAKE_ASM_COMPILER> <DEFINES> <FLAGS> -o <OBJECT> -c <SOURCE>

meaning it will include all defines/flags set by add_definition/set_target_properties for COMPILE_DEFINITIONS or COMPILER_FLAGS. Unfortunately if I have something like the following:
add_library(tx-mps-m4 ${KERNEL_SOURCE})
set_target_properties(tx-mps-m4 PROPERTIES COMPILE_FLAGS "-g --cpu=cortex-m4 -O0")

I get the exact same flags (-g --cpu and -O0) passed to the assmebler (armasm) in my case. And the assembler doesn't understand the -O0 and it exists. How can I avoid this situation?
 

> My second questions: The way I pass the lists of sources is kind of ugly
> - e.g. I'm, in-essence, doing double indirection the ${${blah}} thingy.
> What would be the correct way. I tried with ${blah-list} but this skewed
> the arguments order

To get full support for keywords etc. in your own macros/functions, have a
look at CMakeParseArguments.cmake.

Alex
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Separate compile flags for ASM/C compilers and lists

Andreas Pakulat-2
Hi,

On Mon, Sep 16, 2013 at 10:24 AM, Nikolay <[hidden email]> wrote:

On 14 September 2013 09:59, Alexander Neundorf <[hidden email]> wrote:
On Friday 13 September 2013, lorddoskias wrote:
> Hello list,
>
> I have a couple of questions whose answers I couldn't find. So first
> thing's first - I have the following function which I intend to use to
> add a number of library targets:
>
> function(build_mps_m3_lib LIBRARY_NAME C_SOURCE ASM_SOURCE CPU_TYPE)
>      set_property(SOURCE ${${C_SOURCE}} PROPERTY COMPILE_FLAGS "-g
> --cpu=${CPU_TYPE} -O0")
>      set_property(SOURCE ${${ASM_SOURCE}} PROPERTY COMPILE_FLAGS "-g
> --cpu=${CPU_TYPE} --apcs=interwork")
>      add_library(${LIBRARY_NAME}  ${${SOURCE}} ${${ASM_SOURCE}})
>      set(TARGET_DIR "mps-m3")
>      set(ASM_COMPILE_FLAGS "-g --cpu=${CPU_TYPE} --apcs=interwork")
>      #custom armasm command line
>      set(CMAKE_ASM_COMPILE_OBJECT "<CMAKE_ASM_COMPILER>
> ${ASM_COMPILE_FLAGS} <SOURCE> -o <OBJECT>")
>      #set_target_properties(${LIBRARY_NAME} PROPERTIES C_COMPILE_FLAGS
> "-g --cpu=${CPU_TYPE} -O0")
> endfunction(build_mps_m3_lib)
>
>
> What I want to achieve is to have clear separation between the ASM
> compiler flags and the C compiler flags. Since I'm not using the GNU
> (ergo GCC) toolchain I cannot simply set the properties on the resulting
> library target to set the COMPILE_FLAGS. Essentially what I want to
> achieve is being able to set arbitrary compile options for the C and ASM
> compiler WITHOUT both of those interfering.

In general they don't interfer.
What compiler and assembler are you using ?
Maybe you need a new "assembler dialect". Those are quite simply to do, you
can have a look e.g. at the files containing "MASM" in their name in Modules/.

Unfortunately I do not find the statement "In generla they don't interfere to be correct". Here is what I'm talking about:

The default definitions of ASM_COMPILE_OBJECT is : ASM_COMPILE_OBJECTP: <CMAKE_ASM_COMPILER> <DEFINES> <FLAGS> -o <OBJECT> -c <SOURCE>

meaning it will include all defines/flags set by add_definition/set_target_properties for COMPILE_DEFINITIONS or COMPILER_FLAGS. Unfortunately if I have something like the following:
add_library(tx-mps-m4 ${KERNEL_SOURCE})
set_target_properties(tx-mps-m4 PROPERTIES COMPILE_FLAGS "-g --cpu=cortex-m4 -O0")

I get the exact same flags (-g --cpu and -O0) passed to the assmebler (armasm) in my case. And the assembler doesn't understand the -O0 and it exists. How can I avoid this situation?

Don't set those properties on the target. Instead use set_source_file_properties to set those flags that differ between different types of source files. CMake supports setting compile definitions as well as flags for each source file individually.

Andreas


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake