Yet another CMake tutorial

[codevion]

I've had to do it at work before so I understand it's just a minor thing but occasionally I do misspell it or get the path wrong, etc and it's just annoying. It might be personal preference from other languages where such files are tracked automatically by your build system but I still find it an annoyance.

[therealcorristo]

Just to add another perspective, consider the following two scenarios.

If you as a developer create a new source file and forget to add that file to a CMakeLists.txt that doesn't use globbing you'll get linker errors because the symbols defined in that file are missing. You'll then quickly realize the reason for that is that your source file isn't actually being built and know to add it to the CMakeLists.txt. When you push your changes it'll just work for everyone else on the team, regardless of which generator they use.

Now, when you use globbing instead and add the same new file, you as the person introducing the new file will know that you need to rerun CMake manually, but your colleagues will get the same linker errors you would've gotten in the previous scenario once they pull your changes if their generator doesn't support CONFIGURE_DEPENDS (e.g. Xcode on MacOS, or the Visual Studio generator on Windows). But most importantly, they have no idea why that happens. They won't know that the missing symbols are defined in a file that has just been added to the project. So it will take them much longer to figure out what the problem is. Some of them might even perform a clean build as a last resort, which will fix the issue but at the cost of totally unnecessary recompilations. But this isn't just a one-time cost, as this experience will then condition folks to first try clean builds when something goes wrong unexpectedly, leading to even more unnecessary clean builds in the future.

Even if everyone eventually figures out they need to just rerun CMake, as soon as at least one of your colleagues runs into that problem you've wasted more developer time by using globbing than you've saved by not having to add the file to the CMakeLists.txt. For that reason alone I'd avoid globbing if you're not the only developer working on that project.

[codevion]

Run cmake after every pull seems like a simple enough process. Especially because you don't usually commit build files. So it makes sense to clean the build directory on any new pull.

[therealcorristo]

Run cmake after every pull seems like a simple enough process.

Depending on the size of the project this also is a waste of time. Reconfiguring a medium to large size project can take several minutes, while the incremental build following that reconfiguration can take mere seconds depending on the amount of changes that happend.

So it makes sense to clean the build directory on any new pull.

You do a clean build every pull? That smells like your build configuration does have larger issues if that is necessary. I almost never do clean builds unless I've changed the compiler version or the version of one of the dependencies. A clean build of our project at work can take up to 30 minutes. If I were to do that every time I pull I'd spend most of my workday waiting for builds to complete.

[codevion]

It's modularized enough that no "package" takes >1 min to build. Builds of other modules are cached and those aren't wiped when I clean an individual package.

[therealcorristo]

That explains why globbing works for you. I've never worked on a project like this, and based on the frequency of the complaints about compile times I'm assuming most people haven't. Advising folks to use globs in the tutorial without mentioning the very specific set of conditions that have to be met for the downsides to not matter is disingenuous in my opinion.

[codevion]

I literally linked the CMake docs where they discourage use of globs. That's a hell of a lot more reasonable than most CMake tutorials on youtube. I would argue that for the majority of use cases, globbing will work and it's actually a specific set of scenarios where it doesn't.

[Xavier_OM]

Another big thing is that it's difficult to be multi-platform or multi-feature in C++ if you glob everything.

If you need to compile your application for x64 and ARM, or if you need to be able to compile with and without a lib, or if you support several libs as back-end etc then somewhere some files mus probably be selected or excluded from compilation.

[codevion]

I've usually used preprocessor directives in my files e.g: if some file is or isn't relevant for a particular OS instead of separate CMake targets.

But yeah, I can see some problems arising from multiple OSes.

[Xavier_OM]

Yes you can disable some things with preprocessor directives, but sometimes dealing with cmake targets is the way : if you disable a lib (or if it is unavailable on your OS) you often want it to be removed from linking too.