This RFC proposes that we move the cmake version from 3.2 to something more modern.
For building external dependencies such as llvm it would be nice to be able to use Fetch Content which is introduced in cmake 3.11.
CI should be running the minimum required cmake version.
One way to think about the dependency is to look into the default cmake version shipped by ubuntu LTS so most users can build from source with minimum effort:
Most Linux releases ship with cmake >= 3.10.
If a Linux release is EOL do we no longer support it? Building cmake from source is easy. If someone wants to build TVM on an old, unsupported OS building cmake from source is an option.
I agree that it is reasonable to update the cmake version to a certain version supported by Ubuntu LTS.
CC: @tkonolige I think we chatted about this before 
Tend to agree too. I manage a fleet of heterogeneous development boards, many of which are on vendor-slightly customised versions of Ubuntu. Most of their apt repos point to cmake 3.10.
There are a couple that are outdated now, but I think it makes sense to go by minimum default on the oldest Ubuntu LTS, given its probably going to be the lowest common denominator. CMake fails clearly and quickly when the version is too old anyway.
The oldest currently support Ubuntu LTS is 16.04 which is EOL in April, 2021. 16.04 defaults to 3.5.1. 18.04 defaults to 3.10.2. TVM CI uses 3.5.11. If we use the rule “default provided by oldest supported Ubuntu LTS” then we are at 3.5.1 but we will be updating to 3.10.2 in 5 months. Would anyone object if we jumped right to 3.10.2 and then start following the rule from there?
I think bumping to 3.10.2 makes sense
makes sense. one detail: how do we propose to pin the CI to a specific CMake version? I think the kitware apt repo has a bunch of versions, don’t know how far back they go.
Yeah. Sometimes it’s useful to let ci use a higher version. For example, Thrust requires cmake >=3.13.
@areusch We do need to have some way to pin the cmake version but I think that is a whole different discussion we need to have. The problem I have is how do we update CI to use the new version of cmake? That should be pinned in the repo so all we should have to do is to update that pinned version and CI magically starts using the new version. As things stand now we need to get coordination with CI, or at least CI must upgrade the cmake version before we commit any code which uses the updated version.
@kevinthesun I think we want CI to use the exact version that is set as the TVM minimum required version. The reason for this is to check that no cmake features that are more modern than cmake_minimum_required are checked into the repo which would break the build for people actually using the minimum version. This assumes that CI actually builds all TVM configurations which it currently does not.
@rkimball I guess it is a bit different, but it’s fairly related to this proposal as we currently don’t explicitly pin almost anything in the CI. we achieve reproducibility by using the same docker container run-to-run, but we aren’t guaranteed much reproducibility between builds of the docker containers.
I think we can probably solve this with the kitware apt repo, but i’m not sure how long they maintain releases. I used it for µTVM reference vm. here are the versions it sees:
(tvm-I4tr0BH7-py3.6) vagrant@microtvm:~$ apt-cache madison cmake
cmake | 3.19.1-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.19.0-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.18.4-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.18.3-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.18.2-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.18.1-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.18.0-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.17.3-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.17.2-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.17.1-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.17.0-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.16.5-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.16.4-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.16.3-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.16.2-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.16.1-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.16.0-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.15.5-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.15.4-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.15.3-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.15.2-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.15.1-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.15.0-0kitware1 | https://apt.kitware.com/ubuntu bionic/main amd64 Packages
cmake | 3.10.2-1ubuntu2.18.04.1 | http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
cmake | 3.10.2-1ubuntu2 | http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
Revisiting this thread, seems we are converging to 3.10.2, let us leave this thread for a week, and then proceed with the plan