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

Brian Davis bitminer at gmail.com
Wed Aug 23 17:23:21 EDT 2017


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


More information about the CMake mailing list