[CMake] Interface Libraries allow include directories but not link directories.. Why?

Wed Aug 23 18:21:01 EDT 2017

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 at 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 <bitminer at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170823/3546fe46/attachment-0001.html>