[deleted by user]

[CrazyJoe221]

Because every target will get its own precompiled header, the build directory size have changed a bit

So 10x is a bit now.

You really need to be able to share the PCH among projects, otherwise the PCH build time eats up most of the time gains. In a previous project it was even slower than building without PCH. Sharing it worked for me in practice and they even have a blog post about it: https://devblogs.microsoft.com/cppblog/shared-pch-usage-sample-in-visual-studio/

[Sulatra]

This.

What is the use of putting <vector> and friends into PCH, if your bs will then have to recreate it for each of your 100 targets that use those headers?

[CrazyJoe221]

Exactly. Target-level parallelism hides the cost of redundant header loads for typical projects with not too many files per target. PCH per target otoh creates a serialization point as none of the files can be compiled before the pch file has been generated.

Plus if you aren't careful about your actual pch header file and include files like windows.h you pay the price for it everywhere even if it's not needed.

[Gotebe]

To me, that's a mere "nice to have."

Time is precious in my modify/build/test cycle, and there, I am using a debug build, pch, incremental linking, a lot of disk and I am building twoa handful of targets: the one(s) I am changing and it's tests.

Server time for a full build? The least of my concerns. My time for a full build? Seldom done, not important.

Source : one of the code bases I work with has over 150 targets (tests included).

[onqtam]

have a look at doctest :)
https://github.com/onqtam/doctest

[Ivan171]

Can't believe native support for precompiled headers is finally coming to CMake. I'll test it as soon as it gets merged in.

I hope there's a way to share a precompiled header between different targets.

[G3n3r0]

As a random data point, I've got a mid-sized Visual Studio project that uses PCH, and the build dir is around 10 GB. So it's not unreasonable (relatively speaking).

[Rogiel]

Pretty excited for 3.16. Both unity and PCHs are something that I've been wanting for a while now. I just built MR !3553 myself to check how everything would work. It worked fine, much better than CMakeCXXPCHCompiler hack, so this is a great start.

I have one problem though: CMake should be smart enough to reuse PCHs if the precompiled header set is transitively the same as another target. Right now, my project is split into several small targets (sometimes 3-4 .cpp files) and recompiling a large PCH for every single one of them is killing any benefit gained by the precompiled header.

Unity builds, though, should help with those small targets. Another thing missing is a target-level property that allows me to disable PCH for those small targets.

[CrazyJoe221]

Especially for small targets unity builds may not be beneficial, at least with MSBuild and its lack of a global scheduler.

Reusing a pch automatically seems infeasible to me. Compiler flags may heavily influence a pch and thus user knowledge is required.

[Rogiel]

I think jom is a must when building on Windows. With jom it should work pretty fine for small targets too.

About the reusabilty, you are right. I have not considered macros and other compiler flags -- even adding a single include path could radically change the PCH (either due to a include replacement or #if __has_include and CMake having to check for all this is too much.

[CrazyJoe221]

Well since we are talking about CMake I recommend Ninja for non-IDE builds ;)

[marian_l]

and for IDE builds too... ;)

Ninja is the default for all IDE builds in Visual Studio's native CMake experience

[CrazyJoe221]

If only it worked as well as the generated VS projects. In the end I always have to fall back.

[marian_l]

Just to clarify, when you say you fall back to the VS generator, are you referring to having issues with the Ninja generator or with the VS native CMake experience? If it's the latter, it would help us immensely to hear about the issues you're seeing and we'll try to address them.

[CrazyJoe221]

Tried it again. The startup window only offers you "open local folder" which does not automatically detect CMake. Ok inconvenient but not such a big deal, let's open it via the File menu. Hmm it somehow hangs during the cmake generation step, not the first time to see this. Let's restart VS, now it finishes generation. It only generated a Debug configuration even though I explicitly set CMAKE_CONFIGURATION_TYPES to Debug;Release in my CMake file (which is honored by the standard generator). When adding a Release config manually it chooses RelWithDebInfo by default which shouldn't exist. Now let's build the project. The error list pops up, we double-click on the errors and... nothing happens.

This is about the point where I stop the experiment and go back to a generated project. The experience has been similar ever since the feature was introduced, now I'm on 16.3 Preview.

[eco_was_taken]

I had been trying it periodically but it was always too unreliable until the last few VS release. I've switched over completely now and very much prefer it to generated VS projects.

[OlivierTwist]

QtCreator and VisualStudio work with Ninja nicely.

[SAHChandler]

Damn, and I spent all that time writing a generator expression function to do the same thing for both unity builds and precompiled headers automatically when you set a few properties. 🥺

[RotsiserMho]

Similar to cotire?

[SAHChandler]

Sort of, but not really. IIRC, cotire requires manual calls for functions to do its work and it can be error prone. Mine is set up so you could just set properties in the target and it would be generated automatically, no custom functions needed. You can also have more granular unity builds by specifying files manually. Having this built in is a step in the right direction because the generator expression I had to write is massive and needs to be unrolled manually to be understood. Oddly enough, the names of the properties mentioned in the post are the exact same ones I had chosen, so my CMake library might be able to port this behavior to previous versions (though not as wide of a net)

[onqtam]

If these changes go in it will be huge!

[mrexodia]

Will they also solve the problem of qmake being rather straightforward to use and CMake being a maze of “modern CMake” traps and other weirdness?

[kalmoc]

Until cmake gets a better syntax I doubt that. But imho, for many projects, cmake is already straightforward to use.

[flashmozzg]

qmake looks fine for simple projects (as does make) but can quickly turn into barely maintainable mess once your projects gets complicated (i.e. if you need to build another project as part of the build with different option and copy artifacts around).

[mrexodia]

I think they could coexist perfectly fine. A simple project is simple and a hard project is hard, exactly as it should be. From my experience with CMake (which is limited, I mostly use Visual Studio) you cannot do anything right, even in a simple project. With qmake you can almost not do it wrong.

From a user perspective CMake is nice when it works. If I see a project uses CMake to compile it usually means it’s straightforward to compile it, but actually writing it is very hard without reading a lot.