r/cpp•
codevion

Yet another CMake tutorial

Posted Feb 7, 2021, 2:25 PM UTC

059
AlexReinkingYale•

Yet another CMake tutorial written by someone who has no idea how to use CMake.

They glob for sources which is bad enough, but then they glob recursively and without setting CONFIGURE_DEPENDS, which is outright incorrect and won't notice additions or removals of files without rerunning CMake (not just the build tool) manually.

The minimum version is 3.10, which is FAR from modern, while 3.16 is available everywhere and 3.20 is around the corner.

Skipped ahead to the "how to use libraries" section. The code doesn't use imported targets. So, again, not modern. Also, find_library doesn't have a REQUIRED argument until 3.18, so that code will just outright not work on the advertised version. Edit: worse, the video uses SFML in an unsupported way; the variables they expand were removed in 2018 in favor of imported targets. The example code doesn't even work on Ubuntu 20.04 LTS.

Skip this.

30
Pazer2•

The fact that it is possible to make all these mistakes and still have everything appear to work correctly, with no warnings of any kind, is why we need to replace CMake.

19
Mnx72eAB•

This is really the takeaway. I have yet to see an actual canonical cmake. Every single library uses it differently. And so long I'll just use vcxproj and accept my mediocrity

10
AlexReinkingYale•

Expanding variables into target functions was the way things were done in CMake a decade ago in 2.8.x. Imported targets have been available since then and are now the way you're supposed to use it. Reading the CMake official docs/tutorials makes this very clear.

It's possible to make these mistakes and still have everything appear to work in the same way any Turing complete language that's 20+ years old has similar pitfalls. Would you suggest we get rid of C/C++ because they don't warn you about undefined behavior?

5
dr-mrl•

Would you suggest we get rid of C/C++ because they don't warn you about undefined behavior?

Don't like the bear!

1
SE400PPp•

You seem to be knowledgeable about CMake. Is there a resource you would say gets it right? There's just so much when you search.

5
AlexReinkingYale•

Absolutely. Professional CMake by Craig Scott for sure. If you don't have $30 to spend on the book (newer editions are free), spend some time asking questions on the CMake Discourse or on the CppLang #cmake Slack channel, both of which are free.

11
infectedapricot•

glob for sources which is bad enough, but then they glob recursively and without setting CONFIGURE_DEPENDS, which is outright incorrect

You mean I need to rerun cmake . when I add or remove a source file? Dear lord, how will I cope?!

Seriously, I have seen some terrible CMake introductions, with some terrible advice. Some of them just overcomplicate things, some are too hardcoded to specific compilers or otherwise make assumptions that might not always hold (e.g. if you're cross compiling or need to add an installation target or support both static and dynamic linking). But file(GLOB_RECURSE ...) is just not that big of a deal (and CONFIGURE_DEPENDS is an even smaller one). Yes it has some gotchas, which I've been bitten by myself (e.g. making a copy of foo.cpp called foo-copy-tmp.cpp and then getting duplicate symbol errors from the linker) and I lean towards explicitly listing files. But these problems are trivial compared to what can go wrong; your criticism is the CMake equivalent of a debate about code formatting when there are genuine architectural questions at stake. It's just not worth dying on that hill.

Maybe there are bigger problems in this tutorial, I'd have a look if it were an article, but I'm not going to watch a video to find out.

2
AlexReinkingYale•

Maybe there are bigger problems in this tutorial, I'd have a look if it were an article, but I'm not going to watch a video to find out.

You could read my entire comment and find out.

1
infectedapricot•

Not sure that last paragraph was there when I made my comment. I thought I'd at least skimmed your whole comment but maybe I didn't make it to the end. To be honest, you lost credibility with how strongly and indignantly you made your point about GLOBing, so it was a bit exhausting to carry on (a bit like you found OP's video).

The minimum version is 3.10, which is FAR from modern

There are two very different and distinctive styles of using CMake, the legacy 2.x (and before) style and the newer style supported in 3.x. I'd consider "modern CMake" to mean this new style of usage, not necessarily the absolutely newest version. Modern CMake is perfectly possible in 3.10.

The code doesn't use imported targets.

Now this actually is a problem. Imported targets is practically the definition of modern CMake (along with using target_...() commands instead of global ones). If your whole comment was about this rather, or you at least put it at the front, then the discussion would've been a bit more constructive.

1
codevionOP•

Thanks for the feedback. I’ll add some warnings around the rest of it. But can you explain what the alternative to glob_recurse is?

-1†
AlexReinkingYale•

You list the source files manually. There are a lot of reasons for this.

  1. The devs tell you not to. This is huge. It means that when something goes wrong, your bug reports get rejected.
  2. CONFIGURE_DEPENDS is not guaranteed to work on all generators. Edit: a colleague tells me it's broken before Ninja 1.10.2.
  3. When things go wrong, like during a git bisect, it's hard to figure out what went wrong and which file was mistakenly added or ignored.
  4. It gets slower with more files since globbing is slow. It slows down your incremental builds too since it has to re-glob every time (with CONFIGURE_DEPENDS). This is particularly an issue on Windows.

The CONFIGURE_DEPENDS flag makes it so the glob is re-run on every build (eg. Make or Ninja run) so that CMake can run again if the glob result changes. Without it, the build is utterly broken. With it, you still run into issues. List your source files.

8
codevionOP•

Listing files manually is a nonstarter for me and for a lot of other people I talk to. Thank you for mentioning configure_depends though! I’ll add a warning about that.

3†
AlexReinkingYale•

Too bad. Then don't use CMake. You're basically saying "writing bug-free code is a non-starter for me".

6
ucario•

Seriously f*** cmake. The fact your comment exists is why it's a piece of shit

-5
AlexReinkingYale•

So use Meson? I'm not apologizing for CMake here. Use it right or don't use it.

2
Volker_Weissmann•

Step 1: Use Meson

-4†
Superb_Garlic•

Why?

6
Volker_Weissmann•

Because it is better.

-7
Superb_Garlic•

That's a non-answer.

7
Volker_Weissmann•

I know... It is difficult to find a good answer:

I don't know much about cmake, but from what I heard it has two disadvantages two meson

  1. ugly scripting language
  2. Only works with C++

There are some nice talks on YT:

https://youtu.be/SCZLnopmYBM

https://youtu.be/34KzT2yvQuM

-7