<div dir="ltr"><div class="gmail_extra">On Wed, Aug 23, 2017 at 8:07 AM, Clément Gregoire <span dir="ltr"><<a href="mailto:lectem@gmail.com" target="_blank">lectem@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">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 <a href="http://github.com" target="_blank">github.com</a> or used by coverage websites do it wrong.</p></blockquote><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">At the moment the only reference I trust is Daniel's presentation</blockquote><div><br></div></div><div>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:</div><div>- 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).</div><div>- 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.</div><div>- 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.</div><div><div><div>- In general makes lots of mandates without providing any suggestions how/why they should be followed</div><div>- His solution to complex external libraries being hard to use is for them to "just use CMake". This is really offputting.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div></div><div><br></div><div><br></div><div>Much of the rest of this thread seems to be undirected rhetorical rant, so I don't suspect expanding it would lead anywhere.</div><div><br></div><div>Nick</div></div></div></div>