> 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. > > I think that there is just no mechanism for "inherited build properties". >From the docs ( https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html#interface-libraries), INTERFACE targets seems to be meant for header-only libraries.
The "inheritance" mechanism in CMake is mainly setting variables in a given folder, but this is imho not flexible enough, and leads to problems when you want to use your library as a subfolder of another since you don't have an easy way to overwrite "child" variables from a parent scope unless the child scope carefully did set(CMAKE_CXX_FLAGS "-my-flags ${CMAKE_CXX_FLAGS}") every time. > 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.celer...@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 >> http://www.jcelerier.name >> >> On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis <bitmi...@gmail.com> 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/pipermail/cmake/2017-August/066119.html >>> >>> -- 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: >>> 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://public.kitware.com/mailman/listinfo/cmake >>> >> >> > > > -- > Brian J. Davis >
-- 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://public.kitware.com/mailman/listinfo/cmake