CMake - CMake Digest, Vol 160, Issue 65

Send CMake mailing list submissions to cmake@cmake.org To subscribe or unsubscribe via the World Wide Web, visit https://cmake.org or, via email, send a message with subject or body 'help' to cmake-request@cmake.org You can reach the person managing the list at cmake-owner@cmake.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CMake digest..." Today's Topics: 1. Re: Interface Libraries allow include directories but not link directories.. Why? (Brian Davis) 2. Re: Interface Libraries allow include directories but not link directories.. Why? (Jean-Micha?l Celerier) 3. Re: Interface Libraries allow include directories but not link directories.. Why? (Brian Davis) ---------------------------------------------------------------------- Message: 1 Date: Wed, 23 Aug 2017 16:23:21 -0500 From: Brian Davis To: cmake Mailing List Subject: Re: [CMake] Interface Libraries allow include directories but not link directories.. Why? Message-ID: Content-Type: text/plain; charset="utf-8" So there is some odd replies in the cmake mailing list possibly responses to wrong message, but this looked like a response to mine even if the initial reply to bit is not right from Nicholas. Anywho here goes: @Jean-Micha?l Celerier -- snip -- >* - Says that custom functions such as add_{project}_library shouldn't be *used and function definitions should be used as little as possible. Except this just leads to extremely verbose CMakeLists where repeated properties are defined again and again and again. -- snip -- Yes add_project_library were my own and in the process of being deprecated. These were geared directly at two problems in cmake. 1) They were used to get CMake to support the concept of "inherited build properties". 2) As you stated and is still a problem the verbosity of CMake. Where IMO much could be collaped into one call -- snip -- I also never understood how to handle this. -- snip -- I am afraid I don't ultimately have the answer either... I have do some ideas on possibly best course of action. -- snip -- I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR and the SUFFIX property on a specific set of 25 targets amongst ~100 targets. What am I to do ? * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also would be harder to set / unset on specific targets). * calling target_compile_options(...) 25 times ... well I mean, everyone knows it's bad to duplicate code. Especially if the change is meant to be only when a specific option() is enabled, or for debugging purposes * creating a function that would set the correct flags, etc and then call this function for each target is apparently "not modern CMake" either. * creating and linking to "dummy" INTERFACE targets with the flags and properties I want have an awful lot of limitations So what is the right course of actions here ? -- snip -- I have started using add_library( targ INTERFACE ) to imperilment inherited build properties. Yes the naming convention and use/reuse/misuse of add_library is horrid (library) I just posted this which may help: https://cmake.org -- snip -- Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin for $software", "target Bar is an integration test" and set per-group options, flags, properties, etc. Like add_group(PluginGroup) target_compile_definitions(PluginGroup -DBLAH) set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/) set_group(myTarget PluginGroup) // applies everything to the target -- snip -- I won't have all the syntax for what your trying but possibly try: add_library( PluginGroupInterface INTERFACE) target_compile_definitions(PluginGroupInterface -DBLAH) set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/) I add interface, Interface, or _interface to my interface targets I use like this. Note here library in add library does not actually have to have a library (hence my statements to the horrid miss reuse of add_library for this functionality). It can just have build properties that you want a target to later inherit as far as I understand it or as far as I am miss using it if it is meant to be used some other way. then... add_executable( myTarget ) target_link_libraries( myTarget PluginGroupInterface ) Does that work for your needs? -- snip -- Best, ------- Jean-Micha?l Celerier -- snip -- -------------- next part -------------- An HTML attachment was scrubbed... URL: To: Brian Davis Cc: cmake Mailing List Subject: Re: [CMake] Interface Libraries allow include directories but not link directories.. Why? Message-ID: Content-Type: text/plain; charset="utf-8" > Does that work for your needs? Sadly, no (but thanks!). While this is enough for the arguably common use case of include directories, compile flags, etc... there are plenty of things that won't work with this approach. e.g. none of this works for instance: project(foo) add_library(blah INTERFACE) set_property(TARGET blah PROPERTY SUFFIX ".mxe") set_property(TARGET blah PROPERTY CXX_STANDARD 14) set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever") ------- Jean-Micha?l Celerier https://cmake.org On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis wrote: > So there is some odd replies in the cmake mailing list possibly responses to wrong message, but this looked like a response to mine even if the initial reply to bit is not right from Nicholas. Anywho here goes: > > @Jean-Micha?l Celerier > > -- snip -- > >* - Says that custom functions such as add_{project}_library shouldn't be > *used and function definitions should be used as little as possible. Except > this just leads to extremely verbose CMakeLists where repeated properties > are defined again and again and again. > -- snip -- > > Yes add_project_library were my own and in the process of being deprecated. These were geared directly at two problems in cmake. > > 1) They were used to get CMake to support the concept of "inherited build properties". > > 2) As you stated and is still a problem the verbosity of CMake. Where IMO much could be collaped into one call > > > -- snip -- > I also never understood how to handle this. > -- snip -- > > I am afraid I don't ultimately have the answer either... I have do some ideas on possibly best course of action. > > > -- snip -- > I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR > and the SUFFIX property on a specific set of 25 targets amongst ~100 > targets. What am I to do ? > > * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also > would be harder to set / unset on specific targets). > * calling target_compile_options(...) 25 times ... well I mean, everyone > knows it's bad to duplicate code. Especially if the change is meant to be > only when a specific option() is enabled, or for debugging purposes > * creating a function that would set the correct flags, etc and then call > this function for each target is apparently "not modern CMake" either. > * creating and linking to "dummy" INTERFACE targets with the flags and > properties I want have an awful lot of limitations > > So what is the right course of actions here ? > -- snip -- > > I have started using add_library( targ INTERFACE ) to imperilment inherited build properties. Yes the naming convention and use/reuse/misuse of add_library is horrid (library) > > I just posted this which may help: > > https://cmake.org > > -- snip -- > Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin > for $software", "target Bar is an integration test" and set per-group > options, flags, properties, etc. Like > > add_group(PluginGroup) > target_compile_definitions(PluginGroup -DBLAH) > set_property(GROUP PluginGroup PROPERTIES /* whatever in > cmake-properties*/) > set_group(myTarget PluginGroup) // applies everything to the target > -- snip -- > > I won't have all the syntax for what your trying but possibly try: > > add_library( PluginGroupInterface INTERFACE) > target_compile_definitions(PluginGroupInterface -DBLAH) > set_property(GROUP PluginGroup PROPERTIES /* whatever in > cmake-properties*/) > > I add interface, Interface, or _interface to my interface targets I use like this. Note here library in add library does not actually have to have a library (hence my statements to the horrid miss reuse of add_library for this functionality). It can just have build properties that you want a target to later inherit as far as I understand it or as far as I am miss using it if it is meant to be used some other way. > > then... > > add_executable( myTarget ) > > target_link_libraries( > myTarget > PluginGroupInterface > ) > > Does that work for your needs? > > > > -- snip -- > Best, > > ------- > Jean-Micha?l Celerier > > -- snip -- > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > https://cmake.org > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: https://cmake.org > CMake Consulting: https://cmake.org > CMake Training Courses: https://cmake.org > > Visit other Kitware open-source projects at https://cmake.org > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: To: Jean-Micha?l Celerier Cc: cmake Mailing List Subject: Re: [CMake] Interface Libraries allow include directories but not link directories.. Why? Message-ID: Content-Type: text/plain; charset="utf-8" Ok got it sorry to hear that certainly because, as soon as I hear something that would be useful somehow I end up needing it the next day. So sorry for us both. >From what your are saying (and I will take your word for it) the CMake has a another problem in not implementing "inherited build properties" correctly. That is of course if that is what CMake is after with add_library( targ INTERFACE) in the first place. Thanks for the heads up on yet more CMake does not do correctly. I am now climbing upon my "inherited build properties" soap box. It's kinda slippery up here. On Wed, Aug 23, 2017 at 4:57 PM, Jean-Micha?l Celerier < jeanmichael.celerier@gmail.com> wrote: > > Does that work for your needs? > > Sadly, no (but thanks!). While this is enough for the arguably common use > case of include directories, compile flags, etc... there are plenty of > things that won't work with this approach. > > e.g. none of this works for instance: > > project(foo) > > add_library(blah INTERFACE) > set_property(TARGET blah PROPERTY SUFFIX ".mxe") > set_property(TARGET blah PROPERTY CXX_STANDARD 14) > set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever") > > > > > ------- > Jean-Micha?l Celerier > https://cmake.org > > On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis wrote: > >> So there is some odd replies in the cmake mailing list possibly responses to wrong message, but this looked like a response to mine even if the initial reply to bit is not right from Nicholas. Anywho here goes: >> >> @Jean-Micha?l Celerier >> >> -- snip -- >> >* - Says that custom functions such as add_{project}_library shouldn't be >> *used and function definitions should be used as little as possible. Except >> this just leads to extremely verbose CMakeLists where repeated properties >> are defined again and again and again. >> -- snip -- >> >> Yes add_project_library were my own and in the process of being deprecated. These were geared directly at two problems in cmake. >> >> 1) They were used to get CMake to support the concept of "inherited build properties". >> >> 2) As you stated and is still a problem the verbosity of CMake. Where IMO much could be collaped into one call >> >> >> -- snip -- >> I also never understood how to handle this. >> -- snip -- >> >> I am afraid I don't ultimately have the answer either... I have do some ideas on possibly best course of action. >> >> >> -- snip -- >> I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR >> and the SUFFIX property on a specific set of 25 targets amongst ~100 >> targets. What am I to do ? >> >> * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also >> would be harder to set / unset on specific targets). >> * calling target_compile_options(...) 25 times ... well I mean, everyone >> knows it's bad to duplicate code. Especially if the change is meant to be >> only when a specific option() is enabled, or for debugging purposes >> * creating a function that would set the correct flags, etc and then call >> this function for each target is apparently "not modern CMake" either. >> * creating and linking to "dummy" INTERFACE targets with the flags and >> properties I want have an awful lot of limitations >> >> So what is the right course of actions here ? >> -- snip -- >> >> I have started using add_library( targ INTERFACE ) to imperilment inherited build properties. Yes the naming convention and use/reuse/misuse of add_library is horrid (library) >> >> I just posted this which may help: >> >> https://cmake.org >> >> -- snip -- >> Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin >> for $software", "target Bar is an integration test" and set per-group >> options, flags, properties, etc. Like >> >> add_group(PluginGroup) >> target_compile_definitions(PluginGroup -DBLAH) >> set_property(GROUP PluginGroup PROPERTIES /* whatever in >> cmake-properties*/) >> set_group(myTarget PluginGroup) // applies everything to the target >> -- snip -- >> >> I won't have all the syntax for what your trying but possibly try: >> >> add_library( PluginGroupInterface INTERFACE) >> target_compile_definitions(PluginGroupInterface -DBLAH) >> set_property(GROUP PluginGroup PROPERTIES /* whatever in >> cmake-properties*/) >> >> I add interface, Interface, or _interface to my interface targets I use like this. Note here library in add library does not actually have to have a library (hence my statements to the horrid miss reuse of add_library for this functionality). It can just have build properties that you want a target to later inherit as far as I understand it or as far as I am miss using it if it is meant to be used some other way. >> >> then... >> >> add_executable( myTarget ) >> >> target_link_libraries( >> myTarget >> PluginGroupInterface >> ) >> >> Does that work for your needs? >> >> >> >> -- snip -- >> Best, >> >> ------- >> Jean-Micha?l Celerier >> >> -- snip -- >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> https://cmake.org >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: https://cmake.org >> CMake Consulting: https://cmake.org >> CMake Training Courses: https://cmake.org >> >> Visit other Kitware open-source projects at >> https://cmake.org >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org >> > > -- Brian J. Davis -------------- next part -------------- An HTML attachment was scrubbed... URL: