[FR] Improve the performance of building juceaide by forwarding compiler launcher CMake args

Thanks @oli1!

What is the default behavior when building in Release on an up to date CMake? Is it possible to build a pdb in Release and have juceaide stick with Embedded or would a whole plugin project set the policy and have to move to Embedded?

Thanks Oli, juceaide builds quickly with sccache, but then I’m still seeing the PDB error when building my project.

C:\xxx\xxx.cpp: fatal error C1041: cannot open program database 'C:\xxx .. \vc140.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS
cl : Command line warning D9025 : overriding '/Z7' with '/Zi'

I’m able to build if I comment out the following from JUCEHelperTargets.cmake:

    if(needs_debug_flag)
        target_compile_options(juce_recommended_config_flags INTERFACE $<${debug_config}:/Zi>)
    endif()

That led me to put some message() calls after cmake_policy(GET CMP0141 policy_state) - and this reveals that policy_state is empty. I guess this is because JUCE\CMakeLists.txt calls cmake_minimum_required(VERSION 3.22) and this unsets the policy.

So now I’m stuck again!

This appears to happen when CMake decides (or something overrides) the policy or format options. Forcing the option fixes things for me:

set(CMAKE_POLICY_DEFAULT_CMP0141        NEW      CACHE STRING "" FORCE)
set(CMAKE_MSVC_DEBUG_INFORMATION_FORMAT Embedded CACHE STRING "" FORCE)

Similarly setting it on the command line works too:

cmake ^
    -DCMAKE_BUILD_TYPE=Debug ^
    -DCMAKE_C_COMPILER_LAUNCHER=%SCCACHE% ^
    -DCMAKE_CXX_COMPILER_LAUNCHER=%SCCACHE% ^
    -DCMAKE_POLICY_DEFAULT_CMP0141=NEW ^
    -DCMAKE_MSVC_DEBUG_INFORMATION_FORMAT=Embedded ^
    -G"Ninja" ^
    ..

This does indicate that we cannot apply different debug format options per target.

1 Like

Thanks Oli, I didn’t know about FORCE. Works nicely now, and I don’t currently have a need to have different debug format options per target.

Note to any other GHA users, if you notice the juceaide build start failing it may be due to chances to sccache. Make sure you use later actions version as follows:

- name: Cache the build
        uses: mozilla-actions/sccache-action@v0.0.8
1 Like

If anyone else is wondering why sccache stopped working and Windows builds are taking forever, it looks like this fix was reverted on develop a couple weeks ago:

Yes, Unfortunately we had reports of ballooning file sizes after changing our default debug information format.

You can still use sccache by following the steps in the breaking changes.

@oli1 Understood!

Unfortunately, I’ve spent more than a couple hours trying to get Windows caching in CI again and I’m not having luck (my builds have deteriorated from 7-8min to 30 min). I’ve tried:

  • passing -DCMAKE_POLICY_DEFAULT_CMP0141=NEW and -DCMAKE_MSVC_DEBUG_INFORMATION_FORMAT=Embedded to configure
  • Calling cmake_policy(SET CMP0141 NEW) and
    set(CMAKE_MSVC_DEBUG_INFORMATION_FORMAT "Embedded" CACHE STRING "" FORCE) before my project call
  • Clearing all my GitHub Actions cache
  • Moving away from the official mozilla github action to running my own sccache server

My configure looks like so:

cmake -B Builds -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER_LAUNCHER=sccache -DCMAKE_CXX_COMPILER_LAUNCHER=sccache  .

I’m wondering if it’s not possible for a JUCE app to work with sccache anymore (as originally discussed in the issue) because:

  • CMake’s default is /Zi.
  • There’s no actual mechanism for juceaide’s build to pick up /Z7 being set by the main project (it’s launched from a brand new call to cmake and our configure options don’t pass through).

For now, I will revert the commit on my fork unless anyone else has other ideas!

Whups, I think I got a bit confused re: whether or not matters if juceaide itself is built with /Zi or /Z7. From reading the code it seems like it will only force a flag (now back to /Zi) when the policy is not set and in Debug.

Pamplejuce does seem to be happily caching on Windows after the change. I’m still wrestling with why my main project refuses to cache on Windows…

Is it just Windows? I’m getting zero cache hits across Win, Win32, macOS, Ubuntu 22.04 & 24.04.

For me it’s just Windows, just on a private project. My private mac builds and pamplejuce (public GitHub Actions) are happily caching away.

Tangent: I’m investigating switching away from using the official action, as it caches each object individually in the (slow) GitHub Actions cache, which adds a lot of overhead. It’s fairly trivial just to run sccache --start-server and then cache the whole directory at the end of the job…

Just to followup — I had moved to starting/stopping sccache manually, and I was only calling sccache --show-stats at the end of the CI run. Apparently the server automatically stops after some minutes of inactivity, at which point it will return all 0s for stats…