Consider switching CESM to a CMake-based build

Abierto
  • ¿Algo no está bien?
#413 2 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
cmake
Área
build-system

Línea de trabajo

El issue no menciona archivos CESM, pruebas ni puntos de entrada. Empieza revisando el build existente basado en make; después, lee el issue 5943 de E3SM enlazado y la documentación del sistema de build para entender la migración propuesta. El trabajo estaría terminado cuando exista un alcance y un plan acordados para reproducir el build actual antes de realizar cualquier refactorización de CMake.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

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 https://github.com/E3SM-Project/E3SM/issues/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.

Lenguaje dominante
Python
Estrellas
493
Forks
253
Merge medio
31 min
PR fusionados (30 d)
5

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ESCOMP/CESM

Todos los issues de ESCOMP/CESM

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.