Previous Episode: torchdeploy
Next Episode: TorchScript

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/documentationIf 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, bazeltools/build_variables.bzl is read from cmake! append_filelistbut 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 commandthe general cmake model: "set a bunch of variables, run a bunch of commands". cmake is VERY GREPPABLEbut not everything is in CMakeLists.txt; check *.cmake toothe 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 itprimary hazard of refactoring: need to make sure all the variables
are setup at the new locationmany directories are not recursive glob, beware of adding new directoriesold 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 thingdon't randomly change things and pray: have hypotheses and test them