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.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
