I talked with Jim Foucar about the E3SM experience in migrating to a CMake-based build system. (The recent context is that they're switching to using a ninja-based build as the backend rather than a make-based build, because ninja allows more parallelism. This is something we could consider in CESM as well if we moved to a CMake-based build. But I also wanted to hear some bigger picture thoughts.)
Jim F says that they find huge benefits in E3SM from using a CMake-based build.
Two examples are:
- This simplifies pulling in 3rd party libraries like NetCDF: They can rely on CMake's find_package mechanism rather than needing to set this up explicitly on every system. This simplifies porting to new systems.
- After an initial case.build, you can drop down into a given source code directory and quickly do an incremental rebuild by just running "make" from that directory. This speeds up the incremental rebuild process, and is more similar to how many projects do their build.
He said that those two examples don't do justice to the numerous benefits they find.
However, he also feels that - based on his experience setting this up for E3SM - this would be a large undertaking. He would estimate a few months of effort for someone who isn't intimately familiar with both CMake and CIME. And he notes that the E3SM CMake build is mostly E3SM-specific, so for the most part we'd need to reimplement what he did on the CESM side – this is not just a matter of leveraging things that now exist in CIME.
For E3SM, he did this in a two-step process. The first step was replicating the current make-based system in CMake, with all of its quirks. The actual implementation of this wasn't terrible - maybe something on the order of 1000 lines of code. Verifying that this gave the same results as before took a lot of work - making sure that all targets were built with the same flags. The second, more recent step was refactoring the Cmake to be more in the style of standard CMake - with CMake-native flags (e.g., for compilation flags), managing 3rd party libraries via CMake mechanisms, etc. See E3SM-Project/E3SM#5943 for details on this second step.
See also https://e3sm.atlassian.net/wiki/spaces/DOC/pages/1011942171/E3SM+Build+System+and+CMake for more details on the E3SM CMake build system.
As a side note, Jim F notes that EAMXX allows both a standalone build and a CIME-based build. There is logic in its CMakeLists determining whether it's doing a standalone or CIME-based build, and acts accordingly. Jim finds benefits from the ability to do a standalone build: this makes the build itself significantly simpler in situations where you don't need CIME. However, he notes that, when you actually want to run the model, CIME is required.
I talked with Jim Foucar about the E3SM experience in migrating to a CMake-based build system. (The recent context is that they're switching to using a ninja-based build as the backend rather than a make-based build, because ninja allows more parallelism. This is something we could consider in CESM as well if we moved to a CMake-based build. But I also wanted to hear some bigger picture thoughts.)
Jim F says that they find huge benefits in E3SM from using a CMake-based build.
Two examples are:
He said that those two examples don't do justice to the numerous benefits they find.
However, he also feels that - based on his experience setting this up for E3SM - this would be a large undertaking. He would estimate a few months of effort for someone who isn't intimately familiar with both CMake and CIME. And he notes that the E3SM CMake build is mostly E3SM-specific, so for the most part we'd need to reimplement what he did on the CESM side – this is not just a matter of leveraging things that now exist in CIME.
For E3SM, he did this in a two-step process. The first step was replicating the current make-based system in CMake, with all of its quirks. The actual implementation of this wasn't terrible - maybe something on the order of 1000 lines of code. Verifying that this gave the same results as before took a lot of work - making sure that all targets were built with the same flags. The second, more recent step was refactoring the Cmake to be more in the style of standard CMake - with CMake-native flags (e.g., for compilation flags), managing 3rd party libraries via CMake mechanisms, etc. See E3SM-Project/E3SM#5943 for details on this second step.
See also https://e3sm.atlassian.net/wiki/spaces/DOC/pages/1011942171/E3SM+Build+System+and+CMake for more details on the E3SM CMake build system.
As a side note, Jim F notes that EAMXX allows both a standalone build and a CIME-based build. There is logic in its CMakeLists determining whether it's doing a standalone or CIME-based build, and acts accordingly. Jim finds benefits from the ability to do a standalone build: this makes the build itself significantly simpler in situations where you don't need CIME. However, he notes that, when you actually want to run the model, CIME is required.