Building arguments to target_comple_definitions()

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

Building arguments to target_comple_definitions()

Rob Boehne

All,

 

I have a complex library that is currently built from archive libs into a shared library – there are seven parts to it, each needs slightly different compile_definitions.

I want to set a variable, with the common definitions, and then add only the sub-lib specific definitions to each.

 

I’m attempting to pass a list to target_compile_definitions() but it complains that the argument is invalid.

Do I need to use a string instead?

 

 

cid:image002.png@01D3D0E3.DCFE6710

Rob Boehne

Senior Software Architect | Datalogics, Inc.

<a href="tel:(312)%20853-8351">+1.312.853.8351 | [hidden email]

datalogics.com | blogs.datalogics.com

Connect with us: Facebook | Twitter | LinkedIn | YouTube

 

 


--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Building arguments to target_comple_definitions()

Chuck Atkins
Hi Robb,

Are you adding the appropriate visibility, i.e. PUBLIC, PRIVATE, or INTERFACE?  You should be able to do the following:

# Translates to -DFOODEF1=hello -DFOODEF2=world
target_compile_definitions(fooTarget PRIVATE FOODEF1=hello FOODEF2=world)

# Translates to -DBARDEF1=baz -DBARDEF2
target_compile_definitions(barTarget PRIVATE BARDEF1=baz BARDEF2)

- Chuck

--

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:
https://cmake.org/mailman/listinfo/cmake

image001.png (166K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building arguments to target_comple_definitions()

Rob Boehne

Chuck,

 

I think I didn’t explain the situation well enough.  Here is a sample pseudo-Cmake input fiile:

 

 

add_library( FooBar  SHARED )

add_library( CHUNK1  OBJECT)

add_library( CHUNK2  OBJECT)

 

set( COMMON   SOME_DEFINE_1  SOME_DEFINE_2  SOME_DEFINE_3 )

 

if( condition )

    list(APPEND COMMON  “CONDITION_TRUE”)

endif()

 

target_compile_definitions( CHUNK1 ${COMMON_DEFINITIONS}  CHUNK1_STUFF CHUNK_NAME=\”One\” )

target_compile_definitions( CHUNK2 ${COMMON_DEFINITIONS}  CHUNK2_STUFF CHUNK_NAME=\”Two\”)

target_compile_definitions( FooBar ${COMMON_DEFINITIONS}  )

 

target_sources( CHUNK1 PRIVATE  chunk_one.cpp )

target_sources( CHUNK2 PRIVATE  chunk_two.cpp )

target_sources( FooBar PRIVATE foobar.cpp )

 

Build commands:

 

$(CXX) -DSOME_DEFINE1 -DSOME_DEFINE_2 -DSOME_DEFINE_3 -DCHUNK1_STUFF -DCHUNK_NAME=\”One\” -c chunk_one.cpp -o chunk_one.o

 

$(CXX) -DSOME_DEFINE1 -DSOME_DEFINE_2 -DSOME_DEFINE_3 -DCHUNK2_STUFF -DCHUNK_NAME=\”Two\” -c chunk_two.cpp -o chunk_two.o

 

$(CXX)  -DSOME_DEFINE1 -DSOME_DEFINE_2 -DSOME_DEFINE_3 -DCHUNK2_STUFF -c foobar.cpp -o foobar.o

 

 

 

 

From: Chuck Atkins <[hidden email]>
Date: Wednesday, October 10, 2018 at 2:11 PM
To: Rob Boehne <[hidden email]>
Cc: CMake Mail List <[hidden email]>
Subject: Re: [CMake] Building arguments to target_comple_definitions()

 

Hi Robb,

 

Are you adding the appropriate visibility, i.e. PUBLIC, PRIVATE, or INTERFACE?  You should be able to do the following:

 

# Translates to -DFOODEF1=hello -DFOODEF2=world

target_compile_definitions(fooTarget PRIVATE FOODEF1=hello FOODEF2=world)

 

# Translates to -DBARDEF1=baz -DBARDEF2

target_compile_definitions(barTarget PRIVATE BARDEF1=baz BARDEF2)

 

- Chuck


--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Building arguments to target_comple_definitions()

Chuck Atkins
Hi Rob,
 

target_compile_definitions( CHUNK1 ${COMMON_DEFINITIONS}  CHUNK1_STUFF CHUNK_NAME=\”One\” )

target_compile_definitions( CHUNK2 ${COMMON_DEFINITIONS}  CHUNK2_STUFF CHUNK_NAME=\”Two\”)

target_compile_definitions( FooBar ${COMMON_DEFINITIONS}  )


This is what I was referring to.  Adding visibility to target_compile_definitions:

target_compile_definitions(CHUNK1 PRIVATE ${COMMON_DEFINITIONS} CHUNK1_STUFF CHUNK_NAME=\"One\")
target_compile_definitions(CHUNK2 PRIVATE ${COMMON_DEFINITIONS} CHUNK2_STUFF CHUNK_NAME=\"Two\")
target_compile_definitions(FooBar PRIVATE ${COMMON_DEFINITIONS})


All of the target_<foo> commands take the format target_foo(target_name USAGE_VISIBILY bar1 bar2 bar3 ...).  target_link_libraries is the exception with everythign being PUBLIC by default but only because it pre-dates all the other target commands.

- Chuck

--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Building arguments to target_comple_definitions()

Rob Boehne

So, are you suggesting that I make a “dummy” target and fill it with the common options in compile_definitions() and include_directories() (et. al.)

Then make my OBJECT libraries (and the shared library) depend on the “dummy” target?

 

If that’s not the suggestion, I’m afraid I don’t see how I can use this to set the common flags

 

 

From: Chuck Atkins <[hidden email]>
Date: Thursday, October 11, 2018 at 2:12 PM
To: Rob Boehne <[hidden email]>
Cc: CMake Mail List <[hidden email]>
Subject: Re: [CMake] Building arguments to target_comple_definitions()

 

Hi Rob,

 

target_compile_definitions( CHUNK1 ${COMMON_DEFINITIONS}  CHUNK1_STUFF CHUNK_NAME=\”One\” )

target_compile_definitions( CHUNK2 ${COMMON_DEFINITIONS}  CHUNK2_STUFF CHUNK_NAME=\”Two\”)

target_compile_definitions( FooBar ${COMMON_DEFINITIONS}  )

 

This is what I was referring to.  Adding visibility to target_compile_definitions:

 

target_compile_definitions(CHUNK1 PRIVATE ${COMMON_DEFINITIONS} CHUNK1_STUFF CHUNK_NAME=\"One\")
target_compile_definitions(CHUNK2 PRIVATE ${COMMON_DEFINITIONS} CHUNK2_STUFF CHUNK_NAME=\"Two\")
target_compile_definitions(FooBar PRIVATE ${COMMON_DEFINITIONS})

 

All of the target_<foo> commands take the format target_foo(target_name USAGE_VISIBILY bar1 bar2 bar3 ...).  target_link_libraries is the exception with everythign being PUBLIC by default but only because it pre-dates all the other target commands.

 

- Chuck


--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Building arguments to target_comple_definitions()

Chuck Atkins

So, are you suggesting that I make a “dummy” target and fill it with the common options in compile_definitions() and include_directories() (et. al.)

Then make my OBJECT libraries (and the shared library) depend on the “dummy” target?

 

If that’s not the suggestion, I’m afraid I don’t see how I can use this to set the common flags


That's certainly one way you can solve the problem, i.e. making an interface library with the common defs, and a good idea at that, but that's not what I was referring to.  I was simply tying to explain that the error your getting trying to pass arguments to target_compile_options is because you're missing the visibility argument.

- Chuck

--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Building arguments to target_comple_definitions()

Rob Boehne

They were elided for brevity –

 

So in CMake parlance, what type is the last argument to target_compile_definitions?  Is it a list, string or something else?

 

From: Chuck Atkins <[hidden email]>
Date: Thursday, October 11, 2018 at 2:55 PM
To: Rob Boehne <[hidden email]>
Cc: CMake Mail List <[hidden email]>
Subject: Re: [CMake] Building arguments to target_comple_definitions()

 

So, are you suggesting that I make a “dummy” target and fill it with the common options in compile_definitions() and include_directories() (et. al.)

Then make my OBJECT libraries (and the shared library) depend on the “dummy” target?

 

If that’s not the suggestion, I’m afraid I don’t see how I can use this to set the common flags

 

That's certainly one way you can solve the problem, i.e. making an interface library with the common defs, and a good idea at that, but that's not what I was referring to.  I was simply tying to explain that the error your getting trying to pass arguments to target_compile_options is because you're missing the visibility argument.

 

- Chuck


--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Building arguments to target_comple_definitions()

Chuck Atkins
 

So in CMake parlance, what type is the last argument to target_compile_definitions?  Is it a list, string or something else?


It's a series of VISIBILITY_SPECIFIER DEF1 DEF2 ... DEFN, so the visibility specifier followed by a list of definitions, optionally followed by another visibility specifier and list of definitions, etc.

add_library(Foo OBJECT Foo.cxx)
target_compile_definitions(Foo
  PUBLIC
    COMMON_DEF_1 COMMON_DEF_2
  PRIVATE
    FOO_SPECIFIC_DEF=42
)

will translate to something like:

c++ -DCOMMON_DEF_1 -DCOMMON_DEF_2 -DFOO_SPECIFIC_DEF=4 -o Foo.cxx.o -c Foo.cxx

- Chuck

 

From: Chuck Atkins <[hidden email]>
Date: Thursday, October 11, 2018 at 2:55 PM
To: Rob Boehne <[hidden email]>
Cc: CMake Mail List <[hidden email]>
Subject: Re: [CMake] Building arguments to target_comple_definitions()

 

So, are you suggesting that I make a “dummy” target and fill it with the common options in compile_definitions() and include_directories() (et. al.)

Then make my OBJECT libraries (and the shared library) depend on the “dummy” target?

 

If that’s not the suggestion, I’m afraid I don’t see how I can use this to set the common flags

 

That's certainly one way you can solve the problem, i.e. making an interface library with the common defs, and a good idea at that, but that's not what I was referring to.  I was simply tying to explain that the error your getting trying to pass arguments to target_compile_options is because you're missing the visibility argument.

 

- Chuck


--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Building arguments to target_comple_definitions()

Rob Boehne

How would one set a variable containing multiple definitions to be passed to target_compile_definitions()  ?

 

From: Chuck Atkins <[hidden email]>
Date: Friday, October 12, 2018 at 1:45 PM
To: Rob Boehne <[hidden email]>
Cc: CMake Mail List <[hidden email]>
Subject: Re: [CMake] Building arguments to target_comple_definitions()

 

 

So in CMake parlance, what type is the last argument to target_compile_definitions?  Is it a list, string or something else?

 

It's a series of VISIBILITY_SPECIFIER DEF1 DEF2 ... DEFN, so the visibility specifier followed by a list of definitions, optionally followed by another visibility specifier and list of definitions, etc.

 

add_library(Foo OBJECT Foo.cxx)

target_compile_definitions(Foo

  PUBLIC

    COMMON_DEF_1 COMMON_DEF_2

  PRIVATE

    FOO_SPECIFIC_DEF=42

)

 

will translate to something like:

 

c++ -DCOMMON_DEF_1 -DCOMMON_DEF_2 -DFOO_SPECIFIC_DEF=4 -o Foo.cxx.o -c Foo.cxx

 

- Chuck

 

 

From: Chuck Atkins <[hidden email]>
Date: Thursday, October 11, 2018 at 2:55 PM
To: Rob Boehne <[hidden email]>
Cc: CMake Mail List <[hidden email]>
Subject: Re: [CMake] Building arguments to target_comple_definitions()

 

So, are you suggesting that I make a “dummy” target and fill it with the common options in compile_definitions() and include_directories() (et. al.)

Then make my OBJECT libraries (and the shared library) depend on the “dummy” target?

 

If that’s not the suggestion, I’m afraid I don’t see how I can use this to set the common flags

 

That's certainly one way you can solve the problem, i.e. making an interface library with the common defs, and a good idea at that, but that's not what I was referring to.  I was simply tying to explain that the error your getting trying to pass arguments to target_compile_options is because you're missing the visibility argument.

 

- Chuck


--

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:
https://cmake.org/mailman/listinfo/cmake