Hello all.
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?
Refs: Bump CMake version to 3.18. by zoecarver · Pull Request #36094 · apple/swift · GitHub
(I'm not opposed to bumping the version but:) Could you point out why we are bumping the version? That information might be helpful in investigating CMake failures.
What is LLVM using now?
What is LLVM using now?
According to their docs, 3.13.4 or higher.
(I'm not opposed to bumping the version but:) Could you point out why we are bumping the version? That information might be helpful in investigating CMake failures.
As I understand it, there are some improvements/fixes for linking Swift programs. However, I don't really know the details on this. Maybe @compnerd can elaborate a bit.
uswift, which I'm proposing we add as a dependency, requires version 3.18. In the future, other dependencies might require newer versions of cmake as well.
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.
It sounds like you want to do this b/c of 2. What is this? Bumping the cmake version is a big thing to do. What is this "uswift"? And what are you really trying to do.
It sounds like you want to do this b/c of 2. What is this? Bumping the cmake version is a big thing to do. What is this "uswift"? And what are you really trying to do.
uSwift is a "micro" Swift standard library created by @compnerd. As I discuss in the forum post here and the PR here, I'd like to use this to cross-compile some of the C++ interop tests.
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.
Just to follow up on this. We are actually going to bump to 3.19.6. This has a bunch of swift fixes in cmake that we want.
NOTE: We are beginning the process of doing this/updating all of the bots. I am going to wait a little bit to set the minimum required version.
Part of the reason that we are doing this now is that release/5.5 is branched so this is the time (early) to get in new things like this.
Also to be clear, the reason why we are picking 3.19.6 specifically is that it has important fixes for CMake swift support that we want.
Perhaps.
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.