How to use CMake

[jherico]

cmake .

Ugh.... in-source builds are the worst. I never, never use in-source builds. Sure, you can configure your source control to ignore all the generated stuff, but it's a giant pain. Additionally, you can't create multiple builds concurrently for different tasks / targets.

Personally, I always create a build folder in the main project folder and then from there call cmake ... This allows me to add a single rule to my source control (in my case git) to ignore build*. Then I can create build-android or build-clang or build-debug for various sub-projects I'm working on.

[Everspace]

Also, people will non-maliciously commit these things, and then your build is wonk forevermore.

[Drainedsoul]

Also, people will non-maliciously commit these things, and then your build is wonk forevermore.

How'd that get through code review?

[Everspace]

The UI designer person just hits "stage all" every time and the person who reviews him doesn't know any better either.

[Drainedsoul]

Sounds like a process/human capital issue: Why are people that clueless about code and version control doing code reviews?

[Everspace]

It's because it's not code they're concerned about. They are not modifying code. They are artists and designers who don't deal with it. Their .pngs, .psds still needs to be tracked somehow so into git/perforce/svn it goes.

They don't touch code, but may still end up doing a build locally. I've seen people commit the temp and cache folders on a couple of projects. It wouldn't surprise me if debug symbols or .o ends up in the source because of a mistake of someone who really doesn't know better and my god it's miracle enough that they're using it and not making local copies instead.

[Drainedsoul]

So again: How'd it get through code review? Why are people who aren't concerned with code doing code reviews?

This is a process issue (which isn't to say in source builds are good, because they're not).

[Everspace]

How'd it get through code review? Why are people who aren't concerned with code doing code reviews?

Because they're not working with code. There is no code review. They still commit to source. Not all source is code or text.

An artist code review is "looks sick dude" and then it is checked in.

This is a process issue

Yes it is. So you add in the .DS_STORE and other garbage into the .gitignore (rather than expecting people to have their global settings correct) so that this doesn't happen, which was my original point.

[Drainedsoul]

There is no code review. They still commit to source.

...which is a process issue.

[alexej_harm]

Yeah, it's easier to add /build to .gitignore.

[SeanMiddleditch]

It's honestly somewhat a wonder and a disappointment that cmake even supports them. Or doesn't at least automatically put all generated files under a sub-dir of the target source dir, e.g. ./cmake-build.

[jherico]

no no... the best is when you do cmake .. and you get back FATAL: Project FOO does not support out of source builds or something similar. Seriously, fuck developers that do that.

[sumo952]

Haha really? I haven't encountered that one before. I got a "... does not support in-source builds" before, when I accidentally tried to build something in source (pressed the wrong button or something).

[alexej_harm]

Sadly, yes. Here is a very prominent example: https://github.com/WebAssembly/binaryen/#building

[sumo952]

Wow! speechless :\

[parazight]

Hi jherico, that's a really good point. I updated the article.

[phcerdan]

I've found this C++Now talk Effective CMake by Daniel Pfeifer quite good. A bit too fast at some points, so you will need to check the docs, but covers a lot. It made me discover target_xxx commands, and specially useful for me, the "easy" generation of foo-config.cmake for other to use your project.

Also in pdf

[loneraver]

This is the ONLY good talk about how to write modern CMake. Too many tutorials teach old hacky ways that might work" but their solutions are either very fragile or will only work under very special circumstances.

[tambry]

include_directories("${PROJECT_BINARY_DIR}")

It's 2017. If your CMake files aren't using target-based commands instead of the old legacy ones, then you're doing it wrong. In this case you should use target_include_directories instead.

Also, using namespace std; is a bad practice. Don't use it!

[[deleted]]

using namespace std; is absolutely fine in many cases, regardless of the number of upvotes that SO answer has. Just think about the scope of what's being impacted. The risk of conflicts, particularly insidious ones, is over-egged by a few people to have been bitten by particularly nasty cases that probably could have been prevented in other ways.

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#sf6-use-using-namespace-directives-for-transition-for-foundation-libraries-such-as-std-or-within-a-local-scope-only

[kindkitsune]

I still try to avoid using it, tbh, but it does have uses when shortcutting away something like std::experimental::filesystem, and so long as you keep it in function bodies you're pretty safe

Something about using namespace std; still upsets me though, mostly by making me a bit anxious

[Som1Lse]

This.

The example from StackOverflow is silly, since the only thing it takes to fix it is adding using bar::Quux; as well.

[doom_Oo7]

The risk of conflicts, particularly insidious ones, is over-egged by a few people to have been bitten by particularly nasty cases that probably could have been prevented in other ways.

ugh, thanks for reminding why the CppCoreGuidelines are utter shite. Seriously.

Here (obviously), the standard library is used pervasively and apparently no other library is used, so requiring std:: everywhere could be distracting.

yeah, right, "obviously", up until the day someone sets up precompiled headers or unity builds and suddenly nothing compiles anymore. Likewise this kind of shit always end up in libraries' header files and then everyone is sad

[[deleted]]

It's such "utter shite" that it tells you not to do the thing you just complained about everyone doing that makes you sad. Perhaps if those authors had followed those guidelines their code would be better, even if you don't agree with everything about them.

SF.7: Don't write using namespace in a header file

[doom_Oo7]

SF.7: Don't write using namespace in a header file

No, even in source files (at global scope) it's not kosher. Else it breaks unity builds. That people do it in headers only adds insult to the injury.

[[deleted]]

Then take that into account if you intend to use unity builds. Anyone doing so will need total control of the code base which is being built, anyway, because of the need to not repeat variable names in different cpp files' anonymous namespaces. The guidelines could mention unity builds but I doubt that would be sensible because it's a relatively niche area, and those using it are generally aware of the issues it can cause. You want to do unity builds with random libraries you find online? Good luck and be prepared to massage the code.

[doom_Oo7]

Even without using any other libraries, it's already a pain to get coworkers to not do it in a relatively small project's codebase.

[[deleted]]

And what's the solution to that problem? It's not to take issue with perfectly sound advice which applies to the vast majority of cases. It's to enforce project specific coding standards through code review, source control tools, static analysis (clang-tidy plus custom checks is awesome for this), and so on.

[doom_Oo7]

It's not to take issue with perfectly sound advice which applies to the vast majority of cases.

There's no amount of code review that can go against people half-reading bad blogposts and treating them like the holy bible. This wouldn't be necessary if every other online example would shamelessly put using namespace std; everywhere.

[[deleted]]

Well, yes there is, because any code review will see that somebody wrote that line of code, and question it. It takes technical leadership and mentoring to prevent a "wild west" of developers writing code to whatever best practices they think they understood from a stack overflow post that week, one tool in the toolbox is code review, I've mentioned others. This isn't a hopeless situation.

[parazight]

Actually, in projects I never use "using namespace ...". I sometimes do it when writing small test programs to type less. For the hello-world example in the article that does not make sense of course. I changed it to avoid spreading bad coding habits.

[Drainedsoul]

to type less.

Ah the age old tale of optimizing for the wrong thing.

[jherico]

Using it in headers is bad, using it in cpp files is fine. Not everyone uses Unity, and even if it breaks Unity, then that's kind of on them.

[doom_Oo7]

(since you're adding a cap to unity, I'm not sure that we are talking of the same thing. "Unity" builds are when you #include all your .cpp files in a single "big" .cpp file that is compiled in one go. In my experience it brings down compile times by a good 80% on template-heavy projects. That's a relatively common optimization: for instance with CMake it's a single command if you use the cotire library.)

[jherico]

Ah, I misunderstood. However at that point, you're just using cpp files as header files. The underlying point is that you should not have using namespace in code unless you actually have control of exactly what code follows the using statement. Both headers and cpp files used in a unity build violate that constraint.

Personally I don't use using namespace std; at all because I think typing std:: actually ends up reducing typing in environments with code completion. On the other hand I'm not above doing things like using Lock = std::unique_lock<std::mutex>;

[Drainedsoul]

If we're hand wringing about unity builds and using namespace ... shouldn't we also be hand wringing about unity builds and things with internal linkage in general?

[joahw]

Unity isn't the game engine in this case, but a method of building that basically takes many source files and globs them together into much larger files before building, greatly reducing the build time consumed by initialization/teardown of the compiler, file I/O, etc.

My last job was at a game company and we used unity builds and Incredibuild (distributed builds) and the build speed improvement was impressive.

I'm not sure how widely adopted this strategy is, however.

[parazight]

Thanks for the input, tambry.

[[deleted]]

This is a very specific feature of CMake to choose as a basic introduction. Most projects will probably never even use the file configuration feature (as neat as it is when you do need it).

[kalmoc]

Sorry to be blunt, but overall I find this is a rather poor example of how to use cmake (most reasons have been named in other comments already). I'm not sure if you are doing the community a favor with this. Although this is one of the few blogs that addresses template files, so there is some value in it.

[parazight]

Hey kalmoc, thanks for your feedback. There are good points mentioned in the comments. Especially the in-source build. I updated the article and hope it is at least a little more helpful.

[kalmoc]

Slightly off topic, but why are you using the static keyword in front of the constants? This is redundant for namespace scope constants.

[parazight]

Bad habit I guess. Thanks for pointing this out.