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

Thu Aug 24 03:46:17 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.
>
>
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.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/20170824/e4ed8b69/attachment.html>