docs/modern-cmake
docs
/
modern-cmake
mirror of
1
0
Fork 0
Code Issues Releases Wiki Activity

chore: update pip mention and some versions

This commit is contained in:
Henry Schreiner 2021-10-18 12:16:46 -04:00
parent a279b00ba5
commit 7e76202318
No known key found for this signature in database
GPG Key ID: B9D0E45146A241E8
3 changed files with 39 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -76,7 +76,7 @@ This book tries to solve the problem of the poor examples and best practices tha
Other material from the original author of this book:
* [HSF CMake Training][]
* [Interactive Modern CMake talk](https://gitlab.com/CLIUtils/modern-cmake-interactive-talk)
* [Interactive Modern CMake talks](https://gitlab.com/CLIUtils/modern-cmake-interactive-talk)
There are some other places to find good information on the web. Here are some of them:

30
chapters/intro/dodonot.md
View File

@ -23,6 +23,36 @@ The next two lists are heavily based on the excellent gist [Effective Modern CMa
* **Use `cmake_policy` and/or range of versions**: Policies change for a reason. Only piecemeal set OLD policies if you have to.
## Selecting a minimum in 2021:
What minimum CMake should you _run_ locally, and what minimum should you _support_ for people using your
code? Since you are reading this, you should be able to get a release in the last few versions of CMake;
do that, it will make your development easier. For support, there are two ways to pick minimums: based on
features added (which is what a developer cares about), or on common pre-installed CMakes (which is what a
user cares about).
Never select a minimum version older than the oldest compiler version you support. CMake should always be
at least as new as your compiler.
### What minimum to choose - OS support:
* 3.4: The bare minimum. Never set less.
* 3.7: Debian old-stable.
* 3.10: Ubuntu 18.04.
* 3.11: CentOS 8 (use EPEL or AppSteams, though)
* 3.13: Debian stable.
* 3.16: Ubuntu 20.04.
* 3.19: First to support Apple Silicon.
* latest: pip/conda-forge/homebew/chocolaty, ect.
### What minimum to choose - Features:
* 3.8: C++ meta features, CUDA, lots more
* 3.11: `IMPORTED INTERFACE` setting, faster, FetchContent, `COMPILE_LANGUAGE` in IDEs
* 3.12: C++20, `cmake --build build -j N`, `SHELL:`, FindPython
* 3.14/3.15: CLI, FindPython updates
* 3.16: Unity builds / precompiled headers, CUDA meta features
* 3.17/3.18: Lots more CUDA, metaprogramming
[Effective Modern CMake]: https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1

14
chapters/intro/installing.md
View File

@ -11,7 +11,7 @@ If you have a built in copy of CMake, it isn't special or customized for your sy
Ordered by author preference:
* All
- [Pip][PyPI] (official, sometimes delayed slightly)
- [Pip][PyPI] (official, often updates same-day)
- [Anaconda][] / [Conda-Forge][]
* Windows
- [Chocolatey][]
@ -126,9 +126,9 @@ Just `pip install cmake` on many systems. Add `--user` if you have to (modern pi
|---------------|---------------|-------|
| [TravisCI Xenial](https://docs.travis-ci.com/user/reference/xenial/#compilers-and-build-toolchain) | 3.12.4 | Mid November 2018 this image became ready for widescale use. |
| [TravisCI Bionic](https://docs.travis-ci.com/user/reference/bionic/#compilers-and-build-toolchain) | 3.12.4 | Same as Xenial at the moment. |
| [Azure DevOps 18.04](https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops#use-a-microsoft-hosted-agent) | 3.17.0 | |
| [GitHub Actions 18.04](https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu1804-README.md) | 3.17.0 | Mostly in sync with Azure DevOps |
| [GitHub Actions 20.04](https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-README.md) | 3.17.0 | Mostly in sync with Azure DevOps |
| [Azure DevOps 18.04](https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops#use-a-microsoft-hosted-agent) | 3.21.3 | kept up to date |
| [GitHub Actions 18.04](https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu1804-README.md) | 3.21.3 | Same runners as Azure DevOps |
| [GitHub Actions 20.04](https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-README.md) | 3.21.3 | Same runners as Azure DevOps |
If you are using GitHub Actions, also see the [jwlawson/actions-setup-cmake](https://github.com/marketplace/actions/actions-setup-cmake) action, which can install your selection of CMake, even in a docker action run.
@ -143,16 +143,18 @@ Also see [pkgs.org/download/cmake](https://pkgs.org/download/cmake).
## Pip
[This][PyPI] is also provided as an official package, maintained by the authors of CMake at KitWare. It's a rather new method, and might fail on some systems (Alpine isn't supported last I checked, but that has a recent CMake), but works really well when it works (like on Travis CI). If you have pip (Python's package installer), you can do:
[This][PyPI] is also provided as an official package, maintained by the authors of CMake at KitWare and several PyPA members, including myself. It's now supported on special architectures, like PowerPC on Linux and Apple Silicon on macOS, and on MUSL systems like Alpine too. If you have pip (Python's package installer), you can do:
```term
gitbook $ pip install cmake
```
And as long as a binary exists for your system, you'll be up-and-running almost immediately. If a binary doesn't exist, it will try to use KitWare's `scikit-build` package to build, which currently can't be listed as a dependency in the packaging system, and might even require (an older) copy of CMake to build. So only use this system if binaries exist, which is most of the time.
And as long as a binary exists for your system, you'll be up-and-running almost immediately. If a binary doesn't exist, it will try to use KitWare's `scikit-build` package to build, and will require an older copy of CMake to build. So only use this system if binaries exist, which is most of the time.
This has the benefit of respecting your current virtual environment, as well. It really shines when placed in a `pyproject.toml` file, however - it will only be installed to build your package, and will not remain afterwords! Fantastic.
This also, of course, works with pipx. So you can even use `pipx run cmake` to run CMake in a disposable virtual environment, without any setup - and this works out-of-the-box on GitHub Actions, since `pipx` is a supported package manager there!
{% hint style='info' %}
Personally, on Linux, I put versions of CMake in folders, like `/opt/cmake312` or `~/opt/cmake312`, and then add them to [LMod][]. See [`envmodule_setup`][envmodule_setup] for help setting up an LMod system on macOS or Linux. It takes a bit to learn, but is a great way to manage package and compiler versions.
[envmodule_setup]: https://github.com/CLIUtils/envmodule_setup