Okkoma
commented
5 days ago In PR #81, we cache the build folder containing all CMake files, then clean it up after the build to reduce cache size. This is helpful for the next build but only if the current build succeeds. This approach is the one currently use on other platforms and could address the mentioned issue.
We could improve this process by splitting it into two separate jobs. The first job would check if a cache exists; if not, it would run CMake and then exit (implicitly saving this small folder "build" in the cache). The second job would then retrieve this cache, quickly run the CMake task, and proceed with the build, installation, publication and clean the folder build. This way, even if one of the steps in the second job fails, we will still have a CMake cache.
The CMake step of the CI runs take about 7 minutes for MacOS, and about 12 minutes for iOS. In contrast, it takes about 1.5 minutes on Windows and 0.25 minutes on Linux. Just watching the builds progressing, it seems to be that the tests for headers/functions/macros is fairly slow (a couple seconds each, maybe).
Possibly we should consider caching some of the results of the header/function/macro checks, e.g. using something like https://github.com/cristianadam/cmake-checks-cache.
Additionally/alternatively, we can see if some of the checks can be grouped together CHECK_INCLUDE_FILES instead of CHECK_INCLUDE_FILE to reduce the total number of checks.