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

[Jean-Michaël Celerier]

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

I also never understood how to handle this.

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 ?

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

Best,

-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, Aug 23, 2017 at 1:30 PM, Uwe Koloska <uwe.koloska at voiceinterconnect
.de> wrote:

> On 23.08.2017 11:44, Nicholas Devenish wrote:
> > - But simultaneously advocates rewriting internal functions using the
> > (undocumented?) '_' feature to access "previous definitions". Uses this
> > as one of the few examples of one of the steps as a method to allow a
> > script to change behaviour if being included.
>
> I have raised an issue on this undocumented behavior:
> https://gitlab.kitware.com/cmake/cmake/issues/17199
>
> Regards
> Uwe
>
> --
> Dipl.-Ing. Uwe Koloska
> Chief Software Evangelist
>
> voice INTER connect GmbH               Tel +49 351 407 526 50
> Ammonstraße 35                         Fax +49 351 407 526 55
> 01067 Dresden - Germany                www.voiceinterconnect.de
>
> Geschäftsführung:  Dr.-Ing. Diane Hirschfeld, Ludwig Linkenheil
> Eingetragen im Handelsregister:   Amtsgericht Dresden HRB 19466
>
> voiceINTERconnect www.voiceinterconnect.de
>                      ... smart speech applications from Germany
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170823/6654fa42/attachment.html>