CMake

PyTorch Developer Podcast

Why is PyTorch's build so g-dang complicated. How to avoid having to deal with cmake at all? And if you have to deal with cmake, what are the most important things to know? And if you were going to improve our cmake, how would you go about doing it...

Further reading.

• The official CMake documentation is a great help and well worth reading https://cmake.org/documentation
• If you work in torch/csrc chances are you'll need to edit this file https://github.com/pytorch/pytorch/blob/master/tools/build_variables.bzl

Liner notes.

• multiple build systems: cmake, buck, xplat buck, ovrsource buck, bazel
  • tools/build_variables.bzl is read from cmake! append_filelist
    • but not used uniformly for all components! (ouch!)
• mashed together ATen and Caffe2 build systems (e.g., main library libtorch_cpu is defined in caffe2/CMakeLists.txt)
• cmake: not very much syntax, "everything is a function". This means you can look up constructs relatively easily; e.g., even if() is a command
• the general cmake model: "set a bunch of variables, run a bunch of commands". cmake is VERY GREPPABLE
  • but not everything is in CMakeLists.txt; check *.cmake too
  • the directory structure makes no sense, you really need to grep.
    (doing a lot of set PARENT_SCOPE to propagate stuff)
  • renaming a file? grep for it
  • primary hazard of refactoring: need to make sure all the variables
    are setup at the new location
• many directories are not recursive glob, beware of adding new directories
• old school cmake: literally everything is stuffed in variables (CMAKE_CXX_FLAGS). new school cmake: attach things to targets, things propagate when you depend on targets (public/private dependencies)
• add_library: the most important thing
• don't randomly change things and pray: have hypotheses and test them