Extremely long build times

[SaschaWillems]

A year or two ago we noticed that build times were getting pretty slow. We did several things to improve this and brought down build times to around 4 1/2 minutes (on my setup). I don't know when or why this happened, but as of today, a full rebuild for me now takes ~9 minutes. Pretty much double the time it used to be.

This is esp. frustrating when you're working on the framework, which often requires a rebuild of most samples. Fixing a one-liner and having to wait up to 9 minutes to test something is pretty frustrating. That makes it almost impossible for me to actually work on that part of the samples.

We should take a look at why build times are so bad.

For comparison: A full rebuild of my own samples project (which includes ~100 projects) only takes about one minute.

[gpx1000]

Writing here a list of what I've done and am working on finishing to address this:

• break the circular dependency in the framework that forces us to link the framework as a static build. This alone should net us a big win and something I've been working on for a few years.
• use PCH for specific headers.
• use Unity build option type in CMake.

Other ideas I'm kicking around are platform and compiler dependent (make debug builds faster and linking faster). But once the above is done, we'll see where we are. Oh, and hopefully you're locally building with sccache so you don't have to actually do a full rebuild each time :).
Sadly, I don't think we can do C++20 modules unless Gary's gcc13 is able to use them. That alone would be a big build win. However, i believe the above will net us quite a bit of a gain. I'm instrumenting the build now to be able to report how much of a gain each will give.

[gpx1000]

Circular dependencies are broken, got every sample to work, but ultimately, I've decided that the shared library bullet point wont work. See the linker will recognize that LD_LIBRARY_PATH has Vulkan in it, and when volk goes to initialize inside the framework, it will conflict with the memory of the app when it goes to initialize it. We're stuck with static libraries for now. I'll cleanup everything else and make a PR that might have faster build times from other things. I'm not totally giving up on a shared library, but it is a challenge.

[SaschaWillems]

I tried both ccache and sccache with MSVC to no avail. It seems our CMake setup to find them doesn't work. We have this:

    find_program(CCACHE_FOUND ccache)
    find_program(SCCACHE_FOUND sccache)

Which I think is wrong and should be this:

    find_program(CCACHE_FOUND NAMES ccache)
    find_program(SCCACHE_FOUND NAMES sccache)

With that change, CMake is picking them up for me. But sadly they're not working in MSVC and I have no clue why. Maybe they're not supposed to work with it.

[gpx1000]

mozilla/sccache#107

I think msbuild script would probably help. I'll try to spend more time on this issue this week sorry Sascha

[SaschaWillems]

Is there an immediate workaround I could use for MSVC to help improve build times? I'm currently working on framework-related things, and the long build times are a real hinderance :/