I'd like to propose we update the required CMake version to be 3.18 (the current minimum version for macOS). This is two releases behind the current RC (3.20). If anyone is still using an old CMake, we already have the infrastructure to bootstrap a newer version as part of the build process. Are there any objections to doing this from the community?
In particular, there were fixes related to handling of output locations and fixes related to handling of module search paths and linker search paths for transitive dependencies of targets which required workarounds previously.
Another option would be to actually have two separate versions of CMake and use that specifically for the specific target, but of course that incurs a complexity in the build system.
I'm not suggesting that any one solution is better, just trying to make sure that all the information is available so we can make an informed decision.
Given that how many different failure modes people hit in practice with the build, IMO having a single CMake version is the way to go; if something goes wrong, debugging will be easier with one CMake rather than two.
While you're right that I mainly want to update the CMake version so that we can use uswift, the reason that uswift uses CMake 3.18 (and not an earlier version) is important, and a good reason for us, too, to update our CMake version. Especially as we have more Swift code in the compiler/build pipeline.
I would like to add a +1 to this proposal and a motivating data-point because we ran into a situation where the improvements to building Swift code in CMake 3.17/3.18 are important.
We recently had to revert a change that builds and configures the new integrated swift-driver as the default compiler driver when building Swift:
The reason for the revert is that in CMake versions < 3.17, executable targets do not automatically get rpath linker arguments set up correctly and users running those versions of CMake ended up with a broken driver in their build directory.
Echoing what @compnerd and @zoecarver said above, the increasing amount of Swift code in our code-base makes this an important issue. We may be able to work around this issue with hacks in swift-driver's CMake configuration, but this is certainly not the last such problem we encounter until we switch to a CMake version with better Swift support.
We are already in the process of upgrading to 3.19.6. Infrastructure has a bit of lead time to get everything up to date, so updating to a later version is not possible at this point. I imagine that we will not want to do this for another few months. That will also allow us to provide feedback upstream on any issues that we run into before we upgrade again.
But yes speaking of the near future, I would like to be more aggressive about upgrading the cmake required since we are going to have to provide that feedback upstream (my experience says it is likely). Once the swift support in CMake congeals, we will start upgrading at a much slower cadence since we won't need any fixes from upstream.