Bumping CMake minimum to 3.15

Hello fellow developers,

Now that CMake 3.15 has been out for a while and 3.15.2 is the current release, I would like to propose moving the minimum version for building Swift to jump to 3.15.

I realize that bumping tools is challenging. We have three build hosts to currently consider:

  1. Windows
  2. macOS
  3. Linux

In the case of macOS, the build instructions recommend installing CMake via brew, which has 3.15.2 as the current release (https://formulae.brew.sh/formula/cmake). Although Visual Studio distributes 3.14 still, installation of 3.15 is easy as there is an installer available for Windows. This leaves Linux. Thanks to @spevans, on Linux, we now build CMake if it is not new enough.

This means that CMake is easily available on all the platforms with a new enough version. This means that we can get proper build support for Swift targets, which is extremely helpful in simplifying the build rules for Dispatch, Foundation, and will enable easily bootstrapping swift-package-manager on Windows. Additionally, it also brings along a large number of improvements which will allow us to simplify the current build.

I would like to make this change soon so that we can start cleaning up some of the complexity in the build system.

CC: @spevans @Aciid @mishal_shah @graskind @jrose @Michael_Gottesman @blangmuir

12 Likes

Thanks for driving this. This will also allow SwiftPM to clean up its bootstrapping process and use the CMake setup for all platforms. It would also mean we can finally share some utility code between llbuild and swiftpm.

1 Like

I'm real excited about removing a lot of the cmake boilerplate that exists now :) Nice work getting the swift support into cmake.

Just FYI – CMake 3.15 has definitely not "been out for a while". It's been out for a month. That's all. Not even the forthcoming releases of Fedora 31 and Ubuntu "Eoan" have it (stuck at 3.14.5 and 3.13.4 respectively). This matters because many linux distros are actually derivatives of Fedora or Ubuntu.

In general, I'm not a fan of [bleeding edge] dependencies just to bootstrap a project. It just adds complexity and brittleness, which discourages people from engaging or contributing.

1 Like

Is that not at least somewhat ameliorated by:

I'm just in the minority of users that use CMake directly instead of via the build-script, so I'm in favor of Swift building "out of the box" on semi-recent operating systems (after the prerequisite packages are installed). I can deal with manually building/installing the latest CMake but I feel like I shouldn't have to, especially given that CMake 3.15 was released just a month ago, OSes haven't caught up, and that Swift still works with CMake versions prior to 3.15.

I also build using CMake rather than build-script and am in that same minority as you. I think that the benefit to the the project is still something to consider.

At the very least, I would like to bump the CMake version for the corelibs which stand to have the greatest impact immediately. The builtin support for Swift really allows a lot of simplification, and is required to enable the use of export targets which will allow us to actually simplify the build rules (removing the custom options we have to point out the build tree and source tree for the various corelibs). When we switch export targets, we should also be able to drop all the special library search path and include path handling as the export target can handle that (via interface paths). The other significant benefit is that the documentation and best practices guides become relevant to the projects which should make the build system more approachable to others.

1 Like

I'm fine with bumping the corelibs to require 3.15 and then building CMake 3.15 as long as this is viewed as a temporary solution. Said differently, I hope we aren't still building bleeding edge versions of CMake years from now.

Oh, yes, I definitely agree with you that this should be a short term thing. I see it more as a cost of technical debt that has accumulated in the build system. Once we migrate to the new release and address any issues which may crop up, I hope that we can start tracking the release cycle of the major distributions again (once they catch up). We should aim to make the process as easy as possible for new comers.

2 Likes
Terms of Service

Privacy Policy

Cookie Policy