1
0
mirror of synced 2024-12-23 05:00:01 +01:00

59 lines
3.1 KiB
Markdown
Raw Normal View History

2018-03-30 14:26:33 +02:00
# Do's and Don'ts
## CMake Antipatterns
The next two lists are heavily based on the excellent gist [Effective Modern CMake]. That list is much longer and more detailed, feel free to read it as well.
* **Do not use global functions**: This includes `link_directories`, `include_libraries`, and similar.
* **Don't add unneeded PUBLIC requirements**: You should avoid forcing something on users that is not required (`-Wall`). Make these PRIVATE instead.
2018-07-19 11:54:08 +02:00
* **Don't GLOB files**: Make or another tool will not know if you add files without rerunning CMake. Note that CMake 3.12 adds a `CONFIGURE_DEPENDS` flag that makes this far better if you need to use it.
2018-03-30 14:26:33 +02:00
* **Link to built files directly**: Always link to targets if available.
2020-08-03 18:16:52 -04:00
* **Never skip PUBLIC/PRIVATE when linking**: This causes all future linking to be keyword-less.
2018-03-30 14:26:33 +02:00
## CMake Patterns
* **Treat CMake as code**: It is code. It should be as clean and readable as all other code.
* **Think in targets**: Your targets should represent concepts. Make an (IMPORTED) INTERFACE target for anything that should stay together and link to that.
* **Export your interface**: You should be able to run from build or install.
* **Write a Config.cmake file**: This is what a library author should do to support clients.
* **Make ALIAS targets to keep usage consistent**: Using `add_subdirectory` and `find_package` should provide the same targets and namespaces.
* **Combine common functionality into clearly documented functions or macros**: Functions are better usually.
2020-06-20 19:04:15 +00:00
* **Use lowercase function names**: CMake functions and macros can be called lower or upper case. Always use lower case. Upper case is for variables.
2018-04-25 17:51:02 -04:00
* **Use `cmake_policy` and/or range of versions**: Policies change for a reason. Only piecemeal set OLD policies if you have to.
2018-03-30 14:26:33 +02:00
## 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
2018-03-30 14:26:33 +02:00
[Effective Modern CMake]: https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1