🕺🏻 👲🏾 🥝 Mybuild-モジュラーアプリケーション用のビルドシステム 🦕 👂🏻 🕴🏽

Qtの新しいビルドシステムに関する最近の記事は、数年前に私たちのプロジェクトにあった状況を思い出させてくれました。そして、適切なビルドシステムも探していました。このプロジェクトは非常に複雑であり、柔軟な構成システムが必要です。その結果、独自のビルドシステムMybuildを使用して開発しています。

誰が私たちが何をしたか、そしてそれが独自のビルドシステムを必要としたのはどのようなプロジェクトなのかを知りたいです。

プロジェクトについて

私たちのプロジェクトはEmboxと呼ばれます。これは、組み込みシステム向けのモジュール式で構成可能なOSです。ご覧のとおり、構成可能性は元々プロジェクトのアイデアに基づいていたため、柔軟なビルドシステムが必要です。

最初は、プロジェクトは小さく（現在はそれほど大きくはありませんが）、十分な自作のメイクファイルがあり、その中にすべての構成オプションも設定しました。プロジェクトの開発に伴い、アセンブリのソースコードだけでなくモジュールを記述し、さらにそれらのパラメーターを設定したり、依存関係を記述したりすることさえできるようになるアイデアが現れました。

別のビルドシステム

よくあることですが、食欲は食べることによってもたらされます。機能性（およびそれに伴う松葉杖）は雪だるま式のように成長し、結果として得られるビルドインフラストラクチャを維持するのは非常に不利になりました。それは単に不快でした。

Makeとその派生物に対する批判は、冒頭で述べたmapronの記事にあります。このケースでは、Linuxカーネルで使用されるKbuildアセンブリシステムも考慮したことを付け加えます。私は彼女に少し批判を許します。

アセンブリファイルと構成ファイルは分離されています。したがって、いくつかの場所で説明する必要があります（Makefile + Kconfig）。
構成パラメーターは#defineディレクティブによって設定され、コード内で「#ifdef悪夢」につながることがあります。
オプションの名前空間はありません。

もちろん、次のような利点があります。

Kbuildは、オプション間の依存関係の指定をサポートしています。
いくつかのグラフィカル（および擬似グラフィカル）構成ツールがあります。
持続可能な開発とコミュニティサポート。

何らかの方法で、そのようなシステムは比較的小さなプロジェクトには複雑すぎるように思えました。さらに、すでに小規模な開発が行われていたため、要件を策定し、アセンブリシステムの実装を試みることが決定されました。

だから、私たちはしたい：

アプリケーションモジュールは、できれば使用可能な構成オプションとともに、シンプルで直感的な言語で記述されました。
モジュールの説明には、可能であれば、ユーザーマニュアル、利用可能な単体テストなど、さらに使用するために必要なすべての情報が含まれていました。
ビルドシステムは、PythonインタープリターやJavaマシンのような多くの依存関係を引き出しませんでした。

通常のメイクファイルから始めたため、結果のビルドシステムは純粋なGNU Makeで記述されています。

実装について少し

「純粋なGNU Makeで」と言って、私は少しずるいです。マニュアルの例よりも複雑なものを記述しようとした場合、おそらく組み込み言語の貧困にも注意を向けたでしょう。したがって、私たちが最初に始めたのは、言語の惨めさに対する戦いです。一般に、このトピックは「異常なプログラミング」ハブの別の記事に値します。ここでは、主要な点のみに触れます（私のプロジェクトで誰かが役に立つかもしれません）。

make構文の改善

Make言語は行ベースであるため、複数行で複雑な関数を記述する場合はバックスラッシュが使用されます。これは単に不便であるという事実に加えて、Makeには単一行コメント（グリッドで始まり、行末まで有効）しか含まれていないため、関数内でのコメントの使用を防ぎます。

この制限を修正したので、関数内のコメントとコードのインデント（タブまたはスペース内）を使用して、バックスラッシュなしで複数行の関数を記述できるようになりました。さらに、ラムダ式、インライン単純関数などの機能を言語に追加しました。たとえば、リストを切り替える機能などを書き換える方法は次のとおりです。

だった	になっています
`reverse = \ $(call fold,,$1,__reverse_fold) # Called with the following args: # 1. An already reversed list part. # 2. Next element. __reverse_fold = \ $2 $1`	`define reverse # Start from the empty list. $(fold ,$1, # Prepend each new element ($2) to # the result of previous computations. $(lambda $2 $1)) endef`

だった

になっています

reverse = \ $(call fold,,$1,__reverse_fold) # Called with the following args: # 1. An already reversed list part. # 2. Next element. __reverse_fold = \ $2 $1

 define reverse # Start from the empty list. $(fold ,$1, # Prepend each new element ($2) to # the result of previous computations. $(lambda $2 $1)) endef

OOPを追加

多かれ少なかれ読み取り可能なコードを記述できるようになったので、もう1つバンを追加します。 Makeには入力はなく、データは文字列として表されます。ただし、どのアプリケーションでもデータを構造化する必要があるため、オブジェクトの作成、メソッドの呼び出しなどの機能だけでなく、クラスを定義できるマクロのセットを実装しました。たとえば、greet関数を呼び出すときの次のコードは、「Privet、Habrahabr」を表示します。

 define class-Greeter $(field greeting, $(or $(value 1),Hello)) # Arg 1: who to greet. $(method sayHello, $(info $(get-field greeting), $1!)) endef define greet $(for greeter <- $(new Greeter,Privet), $(invoke greeter->sayHello,Habrahabr) $(greeter))# <- Return the instance. endef

これらの2つの改善の後、開発はずっと速くなり、ビルドシステム自体のロジックに取り組むことができました。

構文について考える

最初に、モジュールと構成の説明の言語を決定する必要があります。原則として、新しい言語には内部または外部DSLが使用されます。内部DSLは汎用言語のサブセットであり、通常は解釈に使用する予定の言語です。 GNU Makeとその不器用な言語の場合、これはまったくオプションではなく、外部DSLのみ、つまり、アセンブリを記述するための独立した言語が残っています。

私は茂みに打ち勝つことはせず、結果の言語はJavaに非常に似ているとすぐに言いません。個人的には、冗長ですが、Java構文が好きですが、多くの点でシンプルで簡単です。 Javaと同様に、Mybuild DSLにはパッケージとインポートがあり、モジュールの説明はクラスの説明に似ています。この言語で記述されたファイルは、my-files（拡張子による）と呼ばれます。

 /* Our first example */ module HelloWorld { source "hello.c" }

言語パーサーの構築

次に、この言語のパーサーを実装する必要があります。また、再帰再帰法やある種の組み合わせライブラリを使用する自己記述型パーサーから、さまざまなパーサージェネレーターまで、多くのオプションがあります。いくつかの実験の結果、私たちは、特に言語の積極的な開発段階で、最も一般的で開発に便利な後者のオプションを決定しました。 GOLD Parser Builder（http://goldparser.org/）をジェネレーターとして使用しました。シンプルな文法記述言語を使用し、デバッガーを内蔵しています。そして最も重要なことは、生成されたパーサーを柔軟に構成できることです（この場合、Make ）

パーサーの結果は解析ツリーです。

オブジェクトモデルの構築

そのため、ファイルからできるだけ多くの情報を抽出し、アセンブリのすべての段階で簡単にアクセスできるようにします。何らかの内部表現が必要であることは明らかです。つまり、解析ツリーをセマンティックモデルに変換する必要があります。

ほぼ同じ段階で、IDEからの言語サポートについて同時に考えました。私たちの場合、プロジェクトの開発者の半数以上がこの特定の環境を使用しているため、これはEclipseです。プラグインを開発するために、 Xtextフレームワークを使用しました。これにより、文法により、構文の強調表示、オートコンプリート、およびその他の最新IDEの機能を備えた本格的なエディターを生成できます。 Xtext自体は、有名なモデリングフレームワークであるEMFに基づいていることをここで言う価値があります。これにより、EMFテクノロジを使用してアセンブリシステム自体を開発するというアイデアが生まれました。

したがって、DSLの構造を記述するEMFモデルを取得します（Xtextによって親切に生成されました）。ここで、Makeでモデルをクラスに変換する必要があります。ここで、 Xpandプロジェクトは私たちの助けになります（Xtextと同じ会社が開発しています）。これにより、テンプレートを使用してモデルからテキストを生成できます。

最後の手順は、解析ツリーの必要なノードのモデルオブジェクトを作成するグルーコードを記述することです。

要件に戻る

依存関係

要件の最初のポイントの1つは、モジュール間の依存関係を定義できることです。まず、ユーザーによる最終アプリケーションの構成を簡素化する必要があります。

my-fileでは、依存関係の指定は次のとおりです。

 module Foo { depends Bar, Baz }

プロジェクトに記述されているすべてのモジュールの完全なグラフが作成されたので、必要なモジュールのサブグラフの閉包の構築は非常に簡単です。

開発を容易にするために、MybuildはGraphvizを使用してモジュールのグラフを視覚化できます。また、例として、単純なEmbox構成のいずれかのモジュールをグラフで視覚化します。

ランタイムブート順序

システムモジュールとそれらの間の依存関係を完全に理解したら、プロジェクトの実際のアセンブリ以外にこの知識を使用してみませんか？たとえば、この情報に基づいて、システム実行中にモジュールがロードされる順序を決定できます。実際、原則として、モジュールのロードは、その依存関係をすべてロードした後にのみ意味をなします。

これを行うために、Cで特別に生成されたソースコードがアセンブリに含まれています。このソースコードでは、依存関係グラフのノードとエッジが静的に定義されています。モジュール自体をコンパイルする場合、すべての依存関係を解決した後にブートローダーマネージャーによって呼び出される初期化関数をモジュールに関連付けることができます。

ビルドオプションとオプション

次のタスクは、特定のモジュールのパラメーターを指定することでした。オプションの構成は、パラメーターを記述するために使用され、パラメーター値へのアクセスは、特別なマクロを使用してコンパイル時に取得できます。

 module HelloWorld { source "hello.c" option string greeting = "Hello, world!" }

 int main(void) { printf("%s\n", OPTION_STRING_GET(greeting)); return 0; }

このオプションはまだあまり快適ではありませんが、現在、モジュールに必要なパラメーター、そのデフォルト値を設定し、構成中にこれらの値をオーバーライドできます。

 configuration Main { include HelloWorld(greeting = "Hello, Habrahabr!") }

リンカースクリプト処理

プロジェクトにやや特有の次の問題は、ソースコード（Cおよびアセンブラー言語）とヘッダーファイルだけでなく、他のリソース（この場合は特別なリンカースクリプトなど）も処理することでした。前処理およびビルドシステムの以前のバージョンのアセンブリに追加のリンカースクリプトを含めるためのメイクファイルは次のとおりでした（さらに、そのようなコードは特別なリンカースクリプトごとに記述する必要がありました）。

 $(IMAGE): $($_heap_lds) $($_heap_lds): $($_SELFDIR)/heap.lds.S $(AUTOCONF_DIR)/config.lds.h @$(MKDIR) $(@D) \ && $(CPP) -P -undef $(CPPFLAGS) \ -imacros $(AUTOCONF_DIR)/config.lds.h \ -MMD -MT $@ -MF $@.d -o $@ $< -include $($_heap_lds).d

これは次のようになり、ビルドシステムは「heap.lds.S」ファイルの処理方法を決定します。

 module HeapAlloc { source "heap.lds.S" }

他のリソースの処理

前の例では、sourceで指定されたファイルの種類の定義は、拡張子（.lds.S）によって発生しました。特定のファイルを特別な方法で処理されるようにマークする必要がある場合があります。たとえば、私たちのプロジェクトでは、これらは実行時にコンテンツを利用できるようにするファイルです。

ここでは、Javaから再度借用した注釈メカニズムを使用しました。彼らの助けを借りて実装した最初のことは、リソースをルートファイルシステムのあるフォルダーにコピーする必要があるとマークする機能です。

 module Httpd { @ InitFS source "index.html" }

アノテーションは、モジュール、その依存関係、ソースコードやパラメーターを含むファイル、その他のアノテーションなど、システム内のあらゆるタイプのオブジェクトに設定できます。したがって、私たちは言語が拡大する良い機会を持っていることを願っています。

継承モジュールと抽象モジュール

最後に、他の同様のプロジェクトでは見られなかった非常に興味深い機能、つまりインターフェイスとその実装を指定する機能について説明します。

高度に設定可能なOSがあるため、たとえば計画戦略などのシステムアルゴリズムを変更する簡単な機会が必要です。 SCHED_FIFO

またはSCHED_OTHER

を使用して各プロセスに設定されるスケジューリングポリシーではなく、スケジューラがすべてのスレッドを制御するアルゴリズム（ポリシーを考慮している可能性があります）。たとえば、現在、プロジェクトは3つの計画戦略を実装しています。最も単純なシステムでは、優先順位または他のフロー属性を考慮しないプリミティブスケジューラを使用できます。また、優先順位を使用して、スレッドが実行されている時間を考慮する戦略があります。

それは小さな余談でした。したがって、インターフェースを使用してシステムの要件を記述し、実装を使用して特定のプロパティを決定できるように、少なくとも単純な継承が必要でした。さて、必要があったので、次のように決定しました。

 @ DefaultImpl(TrivialSchedStrategy) abstract module SchedStrategy { } module TrivialSchedStrategy extends SchedStrategy { source "trivial.c", "trivial.h" } module PriorityBasedSchedStrategy extends SchedStrategy { source "priority_based.c", "priority_based.h" }

ご覧のとおり、アノテーション（ @DefaultImpl

）も@DefaultImpl

では@DefaultImpl

しませ@DefaultImpl

でした。この場合、構成でSchedStrategy

を実装するモジュールが明示的に指定されていない場合、デフォルトでTrivialSchedStrategy

モジュールが使用されます。

おわりに

もちろん、これはシステムのすべての機能ではありません。たとえば、モジュールに特定のコンパイルフラグを指定したり、ユニットテストのセットをそれに関連付けたりすることができます。しかし、とにかく記事が過負荷になっていることがわかったので、Mybuildについてもっと知りたい人は、自分の手でそれを感じたり、コードを調べたりして、プロジェクトwikiでさらに情報を見つけるかもしれません。

もちろん、多くのことを実現し、磨く必要があります。少なくとも、親EmboxプロジェクトからMybuildを解こうとはしていません。一部のドキュメントでは十分なドキュメントなどがありません。

参照資料

最後まで読んでくれてありがとう、コメントであなたの質問や提案に答えてうれしいです。

Mybuild-モジュラーアプリケーション用のビルドシステム