After a very tedious process, I got a log of the PeakPagedMemorySize64 of every TU (provided it lived long enough to do a query).
Everything that reported over a billion has been added to the list.
One file was removed because it didn't actually use that much.
This wasn't entirely foolproof - I can run it again single-threaded so cooperation over codegen threads won't throw the numbers off if this turns out not to fully solve the problem.
* build components so there's something in ccache
* clear the existing cache by using policy: push
* initialise ccache for both groups as components is part of both of them
Qt 6 made it so anything that linked with it had the defines that put the Win32 API into UTF-16 mode.
That means that components (which we reuse the PCH for in multiple targets now) had incompatible defines, and the PCHs wouldn't work.
Before CMP0204, CMake wouldn't set these defines at all except with the Visual Studio generators, so this wasn't causing any problems that caused a compile error when I tested a Ninja-based build.
OPENMW_DOC_BASEURL is only used in a CMake-configured file, so it only needs to be a CMake variable, which it already is.
There's no benefit to making it visible to every TU in components.
MYGUI_DONT_USE_OBSOLETE should be visible in everything that transitively includes MyGUI just in case.
This should really be set up by MyGUI's CMake config or embedded in a generated MyGUI header rather than being our responsibility, but while we're forced to deal with it, it's closer to right to make it a PUBLIC define on components rather than a directory-scoped define in the components directory.
Precompiled headers avoid duplicate work.
If you've only got a single TU using a particular PCH, then there's no duplicate work, so it can only add overhead.
We don't need to totally abandon PCHs for these targets, though, as CMake lets us reuse the PCH from components.
If you've only got a few TUs in a target, it's *probably* faster to get components' PCH for free and eat the cost of it not being perfect than it is to make a perfect PCH from scratch.
Note that I don't know if there are drawbacks due to components having a couple of private precompiled headers that wouldn't have otherwise propagated or these targets having different build flags.
I can't test it locally right now as my linker's regained the deadlocking issue it had the other day.
If it turns out there are problems, then for the single-TU targets, simply avoiding using PCHs for them at all will still be an improvement over the status quo.
For the two-or-three TU targets, we'll have to actually measure things.
This might help diagnose some build problems in the future.
In fact, I need one for MacOS right now, and need to run a job on the upstream CI with this change to get one, so hijacking my existing CI MR seems like a great solution.
