Consider switching CESM to a CMake-based build

オープン
  • 何か問題がありますか？
#413 コメント 2 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
静か
技術スタック
cmake
領域
build-system

調査の方向性

このissueではCESMのファイル、テスト、エントリポイントが指定されていません。まず既存のmakeベースのビルドを確認し、次にリンクされているE3SM issue 5943とビルドシステムのドキュメントを読んで、提案されている移行を理解してください。完了とするには、CMakeのリファクタリングを行う前に、現在のビルドを再現するための合意済みのスコープと計画が必要です。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Python
スター
493
フォーク
253
平均マージ
34分
マージ済み PR（30日）
4

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ESCOMP/CESM のほかの issue

ESCOMP/CESM の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。