Do's and Don'ts
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
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.
- 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_DEPENDSflag that makes this far better if you need to use it.
- Link to built files directly: Always link to targets if available.
- Never skip PUBLIC/PRIVATE when linking: This causes all future linking to be keyword-less.
- 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
find_packageshould provide the same targets and namespaces.
- Combine common functionality into clearly documented functions or macros: Functions are better usually.
- Use lowercase function names: CMake functions and macros can be called lower or upper case. Always user lower case. Upper case is for variables.
cmake_policyand/or range of versions: Policies change for a reason. Only piecemeal set OLD policies if you have to.