The most common situation is when you want to install the latest version of cmake, but your Operating System's repositories are not updated. For example, in my case I have a laptop running Ubuntu 16.04, and when I executed the command sudo apt install cmake the installed version was 3.5.1; instead of 4.0.3 which is the current version at cmake.org.

Teo, how can I get the latest version?

Well, we can install it by following one of these methods:

• Using APT Repositories
• Building and Installing from source
• Using binary files

A. Using APT Repositories (Recommended for normal users)

Kitware now provides an [APT Repository][4] that supports Ubuntu 24.04, 22.04, and 20.04. So we can install it easily following these steps:

A-1. Uninstall the default version provided by Ubuntu's package manager and configuration by using:

sudo apt remove --purge --auto-remove cmake

or:

sudo apt purge --auto-remove cmake

A-2. If you are using a minimal Ubuntu image or a Docker image, you may need to install the following packages:

sudo apt update
sudo apt install ca-certificates gpg wget

A-3. If the kitware-archive-keyring package has not been installed previously, manually obtain a copy of our signing key:

test -f /usr/share/doc/kitware-archive-keyring/copyright ||
wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc 2>/dev/null | gpg --dearmor - | sudo tee /usr/share/keyrings/kitware-archive-keyring.gpg >/dev/null

A-4. Add kitware's repository to your sources list and update.

For Ubuntu Noble Numbat (24.04):

echo 'deb [signed-by=/usr/share/keyrings/kitware-archive-keyring.gpg] https://apt.kitware.com/ubuntu/ noble main' | sudo tee /etc/apt/sources.list.d/kitware.list >/dev/null
sudo apt update

For Ubuntu Jammy Jellyfish (22.04):

echo 'deb [signed-by=/usr/share/keyrings/kitware-archive-keyring.gpg] https://apt.kitware.com/ubuntu/ jammy main' | sudo tee /etc/apt/sources.list.d/kitware.list >/dev/null
sudo apt update

For Ubuntu Focal Fossa (20.04):

echo 'deb [signed-by=/usr/share/keyrings/kitware-archive-keyring.gpg] https://apt.kitware.com/ubuntu/ focal main' | sudo tee /etc/apt/sources.list.d/kitware.list >/dev/null
sudo apt update

A-5. If the kitware-archive-keyring package has not been installed previously, remove the manually obtained signed key to make room for the package:

test -f /usr/share/doc/kitware-archive-keyring/copyright ||
sudo rm /usr/share/keyrings/kitware-archive-keyring.gpg

A-6. Install the kitware-archive-keyring package to ensure that your keyring stays up to date as we rotate our keys:

sudo apt install kitware-archive-keyring

A-7. Finally we can install the cmake package.

sudo apt update
sudo apt install cmake

B. Building and Installing (Recommended for developers)

For this approach you need to install the GCC tools:

sudo apt update
sudo apt install build-essential libtool autoconf unzip wget

B-1. Uninstall the default version provided by Ubuntu's package manager as in A-1.

B-2. Go to the official CMake webpage, then download and extract the latest version. Update the version and build variables in the following command to get the desired version:

version=4.0
build=3
## don't modify from here
mkdir ~/temp
cd ~/temp
wget https://cmake.org/files/v$version/cmake-$version.$build.tar.gz
tar -xzvf cmake-$version.$build.tar.gz
cd cmake-$version.$build/

B-3. Install the extracted source by running:

./bootstrap
make -j$(nproc)
sudo make install

B-4. Test your new cmake version.

$ cmake --version

Results of cmake --version:

cmake version 4.0.X

CMake suite maintained and supported by Kitware (kitware.com/cmake).

C. Using binary files (cmake-gui might not work well)

C-1. Uninstall the default version provided by Ubuntu's package manager as in A-1.

C-2. Go to the official CMake webpage, then download and install the latest .sh version in opt/cmake. Update the version and build variables in the following command to get the desired version:

version=4.0
build=3
## don't modify from here
limit=3.20
result=$(echo "$version >= $limit" | bc -l)
os=$([ "$result" == 1 ] && echo "linux" || echo "Linux")
mkdir ~/temp
cd ~/temp
wget https://cmake.org/files/v$version/cmake-$version.$build-$os-x86_64.sh 
sudo mkdir /opt/cmake
sudo sh cmake-$version.$build-$os-x86_64.sh --prefix=/opt/cmake

C-3. Add the installed binary link to /usr/local/bin/cmake by running this:

sudo ln -s /opt/cmake/bin/cmake /usr/local/bin/cmake

C-4. Test your new cmake version as in B-4.

Note

In 4.0.X the X represents the last part of the version that we defined as build. The build may change if cmake is updated. According to the official web page the Latest Release is 4.0.3. If you want the Previous Release 3.31.6 just replace the version and build parameters like this:

version=3.31
build=6
## don't modify from here
limit=3.20
result=$(echo "$version >= $limit" | bc -l)
os=$([ "$result" == 1 ] && echo "linux" || echo "Linux")
mkdir ~/temp
cd ~/temp
wget https://cmake.org/files/v$version/cmake-$version.$build-$os-x86_64.sh 
sudo mkdir /opt/cmake
sudo sh cmake-$version.$build-$os-x86_64.sh --prefix=/opt/cmake

Observation

For previous versions of CMake (3.19.7 <=), remember that the file name contains an upper case L in -Linux-x86_64.sh and from version 3.20 it has a lower case l in -linux-x86_64.sh

No, this switch does not exist (until CMake 3.15, see my other answer).

If a project uses the install command, it generates the target install. You can call it with

cmake --build . --target install

This uses CMake's Build Tool Mode, which is an abstract interface for a couple of commands to the native build tool (e.g. make or Ninja) and can also be used to pass arbitrary arguments to the native build tool.

You can use the command cmake --build . --target install --config Debug for installation.

CMake's build tool mode supports further arguments that are of interest in this case. You can select the target to build by --target option, the configuration to build by --config option, and pass arguments to the underlying build tool by means of the -- option. See the documentation (Build Tool Mode) for the build-tool-mode.

In CMake 3.15 and newer, you can use the simpler cmake --install command to Install a Project:

cmake --install . --config Debug

It additionally supports --prefix, --component and --strip.

You should download the Windows installer, available here under Binary distributions. You need the x86_64 installer if you're on a 64-bit Windows version, or the i386 installer if you're on a 32-bit Windows version (this should also work on 64-bit Windows versions).

For setting the path, see this question.

You have to think of your folder structures as an "Interface". Then there are three interfaces:

1. source interface
2. build interface
3. install interface

Each interface has a different folder structure with different files in it. The install interface is just the folder structure you get by installing with CMake. Essentially, it takes all your relevant files lying around in your build folder and creates a nice folder structure which other projects can use.

Typically, in an out-of-source build (what is best practice), your source interface will be a subfolder of your project root, e.g., src or source. You then typically configure, generate and build your lib to a directory build which lives right next to src so that your project structure looks like this:

Source and build interfaces:

project_root
├── CMakeLists.txt
├── src
│   └── CMakeLists.txt
├── build
│   └── CMakeCache.txt
...

So that covers the source and build interfaces. But what about the install interface? Answer: The install interface goes wherever the user wants it to go to. The location is specified by CMAKE_INSTALL_PREFIX. You can override it by specifying the --prefix argument:

cmake --install . --prefix "/where/I/want/it/to/go"

This would create the install interface according to the install()-rules you declared in your CMakeLists.txt. For example, if using a default layout using GNUInstallDirs (highly recommended even for windows), this would create a folder structure under /where/I/want/it/to/go/project_root like so:

Install interface:

project_root
├── bin
│   └── executables
├── sbin
│   └── sysadmin executables
├── lib
│   ├── compiled libraries (*.so (unix) or *.dll (windows))
│   └── library archive files (*.lib (windows))
├── libexec
│   └── executables not directly invoked by user
├── include
│   └── header files
├── doc
│   └── documentation

You can see that almost all of the nonsense that we used for developing has vanished and we're left with a pure directory that contains mostly precompiled stuff that other applications can use. You would use the install interface of a project B if your project depends on B and you know that it's going to be installed on Windows or Linux platforms. The install interface is typically not of much use when developing for embedded systems that only run minimal operating systems or none at all, in this case you would build your whole application using the source interface of project B by including it in your project and add it using add_subdirectory().