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

[Nicholas Devenish]

On Wed, Aug 23, 2017 at 8:07 AM, Clément Gregoire <lectem at gmail.com> wrote:

> I entirely agree with for the rest. CMake badly documenting good practices
> or even giving tutorials is an issue. Probably the biggest issue I found. I
> myself still fight after years of using and experimenting with it. This
> lead to a plethora of badly written cmakelists.txt or module scripts, that
> even people in this list still advocates without understanding the problems
> behind it. Even some tutorial series found on github.com or used by
> coverage websites do it wrong.
>
I definitely agree that it's extremely hard to find documentation on good
ways to do things, and I've personally suspected for a while that the total
lack of public information on good/proper/stable way of writing cmakelists
is reflective of an internal situation where there isn't really agreement
on the way things should be done, and that the notion of "Modern CMake" as
something concrete is an entirely public mental construction. (even
interface targets - see how very few FindX modules use them, and of those
that do, the documentation is always buried right at the bottom. But then
even basic FindX things like, how it should handle repeat-inclusion, seems
to be left to discretion of single modules).

Most of the (good/even existing) public documentation I've seen are on
personal blogs, for people who've obviously come onto a project using
CMake, built up required knowledge, and then moved on a year or two later.
And I guess that in general people migrating large projects don't or can't
publicly document the process.

Maybe I'm wrong, and e.g. paying for consulting gives you the very best
advice on the best way of using modern features in complex situations. But
I haven't seen a lot of evidence for it.

At the moment the only reference I trust is Daniel's presentation


Whilst it gives a reasonable overview, even Daniel's presentation I find
rather misleading and (intentionally?) vague on several points, e.g. off
the top of my head:
- Advocates scripts being usable standalone and also includable themselves.
Gives almost no suggestion on how to do this or the many problems that can
arise (I'd love this to be reasonable without writing completely
unidiomatic code).
- 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.
- 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.
- In general makes lots of mandates without providing any suggestions
how/why they should be followed
- His solution to complex external libraries being hard to use is for them
to "just use CMake". This is really offputting.

I'm certain his grasp of these problems is great, and appreciate it's just
a single presentation, but *personally* (and I emphasise this is the way
that *I* view it) find his presentation style hard to follow and it doesn't
leave me with much confidence of the contents.

I suspect this is just a side-effect of having only one real source for
these things, that was never meant to end up as a communities single
reference.



Much of the rest of this thread seems to be undirected rhetorical rant, so
I don't suspect expanding it would lead anywhere.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170823/0f7bbd70/attachment.html>