CMakeでシンプルに：どこでもコーディング、どこでもビルド

組み込み開発チームなら誰もが 経験した ことがあるでしょう。 ベンダーの プロジェクトファイルによって特定のIDEに縛られ、 一方でCIパイプラインでは 別の環境が求められるという 状況です 。Linux開発者は、 GUI主導 の開発から 脱却し、よりスクリプト主導のワークフローを採用するために、 のプロジェクトファイルを手作業で変換しています。また 、 の新しいマイクロコントローラ・バリアント が登場すると 、維持管理すべきプロジェクト構成がさらに増え、その多くはベンダー固有のフォーマットで提供されます。

こうした 摩擦こそが、 組み込み開発が 、ソフトウェアのビルド方法を記述するための共通言語として、 やCMakeへと 収束しつつある大きな理由 の一つです。IDE、コマンドラインツール、CIパイプラインのいずれもが読み取れる単一のビルド記述が、徐々に乖離していく設定の集合体に取って代わるのです。

IARは数十年にわたり独自のプロジェクト形式を採用してきましたが、チームが引き続きそれを利用できるよう完全なサポートは維持されているものの、現在ではCMakeがIARプラットフォーム全体において第一級の選択肢となっています。このブログ記事では、ワークステーションからパイプラインに至るまでの単一のファームウェアプロジェクトを追跡し、それが実際にどのように機能するかを紹介します。

なぜ組み込みチームはCMakeに移行しているのか？

ほとんどのチームは、意図的にビルドを複雑にしているわけではありません。複雑さは徐々に蓄積されていくものです。新しい製品バリエーションには独自の設定が必要になります。2つ目のアーキテクチャが追加されると、プロジェクトファイルも増えます。CIスクリプトでは、IDEにすでに存在する設定が重複し始めます。やがて、本来は同じはずのビルドが、複数のバージョンに分かれ、それぞれが独立して進化していくことになります。

その症状はよく知られたものです：

• IDE、スクリプト、CI間で手動で同期させなければならないプロジェクト設定
• 開発者やチーム間で生じる設定のずれ
• 特定のマシンやOSでしか動作しないビルドスクリプト
• 新しいアーキテクチャやバリエーションの導入に、プロジェクト全体のクローン作成が必要になる
• ビルド情報がファイルと担当者の頭の中という両方に分散しているため、新規メンバーの参入が遅れる

その一方で、環境は変化しました。現在、ビルドはLinux上のコンテナ内でヘッドレスに実行され、デスクトップ環境を見たことのないパイプラインによってトリガーされています。GUIベースのプロジェクト形式内にのみ存在するビルドは、そのような環境ではボトルネックとなります。テキストベースでバージョン管理されたCMake記述は、その環境に自然に適合します。

CMakeは組み込みターゲット向けのクロスコンパイルをどのように処理するのか？

まず、クロスコンパイルを機能させる要素、つまりツールチェーンファイルから見ていきましょう。このファイルは、CMakeに対して、どのコンパイラ、アセンブラ、リンカを使用するか、またどのプラットフォームをターゲットとするかを指示します。Arm用のIARツールチェーン向けの最小限のツールチェーンファイルは、次のようになります：

cmake

# iar-arm.cmake

set(CMAKE_SYSTEM_NAME Generic)

set(CMAKE_SYSTEM_PROCESSOR arm)

set(CMAKE_C_COMPILER iccarm)

set(CMAKE_CXX_COMPILER iccarm)

set(CMAKE_ASM_COMPILER iasmarm)

これで、Linux でも Windows でも、どのターミナルからでも同じプロジェクトの設定とビルドが可能になります:

cmake -S . -B build -G Ninja --toolchain iar-arm.cmake

cmake --build build

プロジェクトが拡大しても、CMakeのターゲット中心の設計により管理しやすさが保たれます。インクルードパス、コンパイラ設定、リンクオプションは、target_include_directories()やtarget_link_libraries() などのコマンドを使用してターゲットに紐付けられ、それらに依存するすべての要素に自動的に反映されます。 ジェネレータ式により、単一のCMakeLists.txtで異なるアーキテクチャ、コンパイラ、ビルドタイプに対応できます。新しいコアやデバイスのバリエーションをサポートする場合でも、プロジェクトをクローンするのではなく、新しいツールチェーンファイルやプリセットを作成するだけで済みます。

CMakeで組み込みテストを実行できますか？

同じビルド記述を用いてテストを実行することも可能です。CTestはCMakeの一部です。add_test()でテストを定義すれば、ソフトウェアのビルドに使用されるのと同じワークフローを通じて実行されます。

ctest --test-dir build

IARユーザーの場合、テストはさらに一歩進んで、C-SPYデバッガー、シミュレータ、またはターゲットハードウェア上で実行できます。C-SPY対応のテストラッパーが各テストを起動し、その出力から合格または不合格を検出するため、CIの結果は開発者がデバッグ時に使用するのと同じ実行環境から得られます。

ビルドとテストが共通の基盤を共有するようになったため、パイプラインと開発者のワークステーションでは、同じ手順が実行され、同じ結果が得られます。

IARのクロスプラットフォームIDEはCMakeとどのように連携するのでしょうか？

CMakeの導入を検討しているチームからよく寄せられる質問は、CMakeプロジェクトを維持したまま、IDEで生産的に作業できるかどうかという点です。 IARのクロスプラットフォームIDEでは、CMakeプロジェクトが「真実の源」であり続けます。 IDEは、プロジェクトを別の形式に変換することなく、LinuxやWindows上で直接開くため、プロジェクトは移植性、スクリプト化が可能であり、CMakeを理解するあらゆるツールで読み取ることができます。

開発者は、本格的なIDEならではの編集、ビルド、およびC-SPYによるデバッグ体験を得ることができます。コマンドライン、CIサーバー、Dockerコンテナは、まったく同じビルド定義を引き続き使用します。 ソースツリーの外に隠れたプロジェクト状態は存在しないため、開発者のマシンでビルドされたものは、Jenkins、GitLab CI、またはGitHub Actionsで実行されるビルドと全く同じものになります。

既存のIARプロジェクトを持つチームは、すべてを一度に切り替える必要はありません。新しいプロジェクトはCMakeで開始でき、既存の製品については現在の設定のまま継続できます。

既存のZephyrプロジェクトをIAR IDEで使用できますか？

Zephyrを使用しているチームにとって、新しい開発環境を試す際の最大の障壁は、通常、移行にかかる労力です。ZephyrプロジェクトはすでにCMakeに基づいて構築され、westツールで管理されており、より優れたデバッガを得るためだけに、正常に動作しているプロジェクトの構造を変更したいと思う人はいません。

IARのクロスプラットフォームIDEは、既存の事前設定済みのZephyrプロジェクトに直接連携します。westのワークフローはそのまま維持され、チームはそれに加えてIARのデバッグおよび分析機能を利用できるようになります。IDEがプロジェクトに適応するのであり、その逆ではありません。

図1：IAR Embedded WorkbenchクロスプラットフォームIDEのスクリーンショット。CMakeベースの組み込みプロジェクトが表示されており、既存のCMakeLists.txtファイルのインポートもサポートされています。 開発者は、既存のCMakeプロジェクトを、編集、ビルド、デバッグ、CI/CD統合のためのフル機能のクロスプラットフォーム環境に直接取り込むことができ、単一のビルド構成を維持できます。

CMakeビルドから静的解析を実行するには？

CMakeベースのワークフローでは、静的解析は、誰かが別途行う必要がある別個のステップではなく、ビルド自体の一部として組み込むことができます。

Zephyr では、ZEPHYR_SCA_VARIANT 変数を使用して、CMake 引数として静的解析ツールを選択します。IAR C-STATを選択すると、開発者がすでに実行しているビルドコマンドに解析が追加されます。

west build -b <board> -- -DZEPHYR_SCA_VARIANT=iar_c_stat

C-STATは、コードをMISRAC、MISRA C++、およびCERT C/C++に照らしてチェックし、検出結果をCWEの脆弱性クラスにマッピングします。 ルールセット、スレッド数、およびアナライザのオプションは CMake 変数を通じて設定されるため、解析設定はコードと同様にバージョン管理され、すべてのワークステーションおよびすべてのパイプラインで同一の動作が保証されます。

CMake ベースのワークフローは、チームにとってどのような意味があるのでしょうか？

開発者にとっては、そのメリットはすぐに実感できます。1 つのプロジェクトで、あらゆるオペレーティングシステムやツールを使用でき、設定を手動で同期させる必要もありません。

エンジニアリングリーダーにとっては、その価値は時間の経過とともに増大します。 重複する設定の整合性を保つために費やされていた時間や、IDEとパイプライン間の不一致によって引き起こされていたCIの失敗は、その根源から排除されます。また、新規メンバーのオンボーディングも迅速化されます。CMakeは業界全体で広く知られているため、新しいエンジニアは、まずツール固有のフォーマットを学ぶ必要がなく、到着した時点でビルドを読み取り、拡張できることがよくあります。

単一のバージョン管理されたビルド記述は、再現可能なビルドの中核となる基盤の一つです。バージョン固定されたツールチェーンや管理されたビルド環境と組み合わせることで、チームは数年後でもまったく同じバイナリを再ビルドできるようになります。これは、「サイバーレジリエンス法」などの規制が厳格化する中で、ますます重要になっている要件です。

これらを総合すると、組み込み開発が向かっている方向性は次の通りです。すなわち、「単一のビルド記述、多様な環境、そしてワークフローを定義するのではなく、ワークフローに溶け込むIDE」です。

実際の動作を確認する

ご自身のプロジェクトで「CMakeファースト」のワークフローを試すか、インタラクティブなIAR Platformデモで各要素がどのように連携するかを確認してください。