On the heels of the recent announcement about Swift support in CMake, I would like to bring up a topic of discussion which I think may take a bit to resolve. I would like to bring this topic up and see if we can come to a decision on what is the best thing to do for the project. The crux of the question is: is it viable to update CMake at a more aggressive pace than the project traditionally has?
CMake gaining proper support for Swift as a language gives a strong motivation for bumping the minimum required CMake for the Swift project. It will enable a very large simplification in the build rules, allowing us to delete hundreds of lines of CMake code. Additionally, we can adopt the general best practices for CMake usage and more modern syntax and idioms. The proper language support enables simpler dependency tracking and also enables the breath of the knowledge on the Internet about CMake behaviours to be applicable to the Swift build as well. This should also enable others to more easily delve into the build system which has largely been a sore point and arguably one of the most complicated build systems. Additionally, this will enable us to create export targets for the core libraries (much like clang/LLVM) and use the libraries from the build trees with CMake handling all the flags and location as well as easing the re-use of the libraries across projects from their respective build trees.
I think that the biggest downside of the upgrade is the fact that we would diverge from clang/LLVM and require a newer CMake than the dependencies. This means that we have to consider what the different environments offer in terms of CMake. On Windows, it seems that the upgrade cycle is actually the easiest - Visual Studio has done an excellent job of keeping up with CMake, and is currently shipping 3.14. The story on macOS is much more interesting, where the package is not available as part of the system or system development tools. However, there are DMGs available from KitWare pretty quickly, so I think that it shouldn't be too bad on macOS either. The one platform where I think that this may be slightly more challenging. Some distributions have the ability to update quickly while others lag behind. It is always possible to build CMake, but that may be additional friction.
Overall, I think that the benefits do outweigh the drawbacks, and that we should upgrade, but that is one person's opinion. I have a couple of patches up as drafts to start exploring what such a world would look like for the core libraries:
These are both the simpler builds that we have that are using Swift, and in both cases, we managed to remove about 300 lines of CMake in each repository. I think that the biggest gain here will be actually in an attempt to port the standard library to this mechanism.
Note that even if we decide to go ahead and bump the CMake version, we should probably do so cautiously optimistically with the 3.15.1 release. But, we should figure out what the change will be so that we can address any issues that come up as we start pushing more complicated real world workloads on the new support.