In the CI setup, xcode-select is only called after the packages have been set up, but during setup we actually need to build the packages from source to have the correct deployment target linked correctly. This means we could potentially be building with the wrong configuration (e.g. when building for 10.9 legacy builds, we could be using an Xcode version that's too new for that) when building gettext/libsodium. This is compounded by the fact that our GitHub Action cache key for the libraries only include the formula, but not the active Xcode version itself so a cache could be propagated for a while until suddenly things break.
To fix this, first make sure we do Xcode configuration early on in the build, and to properly use the Xcode version as part of the cache key. This way, when Xcode version changes, we will invalidate the cache and rebuild gettext / libsodium with the correct configuration and if that's wrong we will immediately fail the build instead of using old stale caches.
In the CI setup, xcode-select is only called after the packages have been set up, but during setup we actually need to build the packages from source to have the correct deployment target linked correctly. This means we could potentially be building with the wrong configuration (e.g. when building for 10.9 legacy builds, we could be using an Xcode version that's too new for that) when building gettext/libsodium. This is compounded by the fact that our GitHub Action cache key for the libraries only include the formula, but not the active Xcode version itself so a cache could be propagated for a while until suddenly things break.
To fix this, first make sure we do Xcode configuration early on in the build, and to properly use the Xcode version as part of the cache key. This way, when Xcode version changes, we will invalidate the cache and rebuild gettext / libsodium with the correct configuration and if that's wrong we will immediately fail the build instead of using old stale caches.