MPS 2019.3ヘルプ

ブートストラップ依存関係の問題の除去

定義:

いつでも

  • それ自体を使用する言語または

  • 言語を使用し、その言語が機能するために同じソリューションを必要とする(つまり、間接的または直接依存する)ソリューション

ブートストラップ依存関係の問題があります。

なぜこれが問題なのですか

  • ビルドスクリプトを使用してプロジェクト全体をゼロから再構築することはできません

  • 生成されたアーティファクトをVCSリポジトリに保持する必要があります

このブートストラップ依存関係サークルは、プロジェクトが完全に一から再構築されることを防ぎます。代わりに、言語を構築するには、ソリューションビルドアーティファクトの以前のバージョンが生成されている必要があります。同様に、ソリューションを構築するには、最初に言語を構築する必要があります。1つのコマンドでプロジェクト全体を再構築することはできません。生成されたアーティファクトをVCSに保持する必要があり、プロジェクトの依存関係構造にはループが含まれます。

MPS 2.5.4以降のビルドスクリプトはMPS コード生成できるため、MPSワークベンチに依存せずにコードを生成できます。ただし、プロジェクト構造内の依存関係のブートストラップは邪魔になります。

MPSの検出および除去ツールチェーン

プロジェクトを完全に再生成できないことは深刻な課題であると考えています。バージョン2.5.4以降のMPSでこのような依存関係をすべて検出し、排除するのに役立つツールを提供することにしました。MPSでプロジェクトを再構築しても何も変わりません。ただし、ビルドスクリプトを再構築する場合、MPSは、それらをエラーとして使用する言語とモジュール間の循環依存関係を検出および報告します。

ビルドスクリプトをリビルドすると、次のようなエラーレポートが表示される場合があります。

mps error

出力テキストには、課題を解決するためのヒントが含まれています: モジュールを右クリック->分析->モジュールの依存関係の分析

depViewer

モジュールの依存関係を表示するアナライザーレポートパネルが表示されます。灰色(ブートストラップ依存関係)インジケーターは、問題のあるブートストラップ依存関係をすべて強調表示するため、すぐに見つけることができます。左側のパネルでいずれかを選択すると、右側のパネルで依存関係の円がさらに詳しく表示されます。モジュールの言語への依存関係が一覧表示され、その後にモジュールへの言語の依存関係が表示されます。これで、問題を解決するために2つの依存関係のどちらを削除するかを選択できます。

問題を修正する

基本的に、依存関係のサイクルを破る必要があります。最初に行う必要があるのは、インポートの最適化を呼び出すことです。モジュール間の依存関係が宣言されているだけでコードで実際に使用されていない場合、これによりそれらが削除され、ブートストラップの問題が解決される可能性があります。問題が解決しない場合は、アナライザーをもう少し試す必要があります。

Editor113

ブートストラップ依存関係の分析

たとえば、言語自体が独自の定義であるブートストラップ言語という問題を頻繁に修正していると想像してください。

selfDependency1

右のパネルには、1つの問題のある依存関係の方向のみが表示されています。

selfDependencyMenu

使用箇所の表示ポップアップメニューコマンドを使用すると、3番目のパネルが表示されます。このパネルには、依存関係が必要な、コード内のすべての具体的な出現が一覧表示されます。

quotation

残念ながら、自分で、どれを削除し、どのように削除するかを決める必要があります。これは手動プロセスになります。

依存関係のブートストラップの典型的なケース

ケース1: 自己参照引用

言語の自己参照につながる間違いの非常に頻繁な例は、たとえば独自の型システム規則を定義するために、引用符で言語を使用することです。独自の型を宣言し、型システムの側面で引用符を使用してこの型をインスタンス化します。ここで、言語はビルドするためにビルドされている必要があります。

H1

軽い引用引用の代わりにそのような状況で使用されるべきです。ノードのエディターを引用で使用することなく、軽量の引用のような機能を提供します。軽い引用が適切なノードを作成するには、コンセプト名と必要な機能を提供する必要があります。

引用から軽い引用への迅速な変換に便利なインテンションも利用できます。

H3

軽い引用引用と比較すると少し便利ですが、ブートストラップの問題を回避します。引用と反引用を大きく組み合わせる必要がある場合、意図をよりよく表現するために引用に好むこともあります。

Editor112

ケース2: 言語は、アクセサーリモデルで自身を使用する

言語にはアクセサーリモデルを含めることができます。これらのアクセサーリモデルが包含言語を使用し、「フラグを生成しない」を選択していない場合、アクセサーリモデルと所有言語の間に循環依存関係が生じます。このような言語は、アクセサーリモデルを言語とともに生成する必要があるため、ゼロから再構築することはできません。

この問題の解決策は、アクセサーリモデルを別のソリューションに移行することです。MPSでは、アクセサーリーモデルを言語の外部に置くことができます。

ケース3:言語はjetbrains.mps.lang.patternによって作成されたパターン内で自身を使用する

この問題は、引用を伴う問題に似ています。言語をゼロから再構築することを禁止していませんが、循環依存関係はそのままです。現在、パターン内の言語の使用を回避するか、ビルドスクリプトで依存関係をブートストラップすることを許可する以外に、それに対する簡単な解決策はありません。

ケース4: 言語のランタイムソリューションは、まったく同じ言語を使用する

言語のランタイムソリューションAは、一般的に言語Aを使用したモデルから生成されます。どんなことで実行されるコードが含まれています。そのため、ランタイムソリューションコードは、生成されたコードと同じ抽象レベル、つまり言語Aレベルの1レベル下に論理的に属します。下位レベルのコードを上位レベルのコードから分離し、プロジェクトを階層的に整理することをお勧めします。

この問題の解決策は、言語Aの使用をランタイムソリューションから別の別のモジュールに移動することです。

他にやるべきこと

すべての問題を個別に攻撃した後、プロジェクトのインポートを最適化し、ビルドスクリプトでディスクからモジュールをリロードする インテンションを呼び出す必要があります。これにより、依存関係構造がクリーンアップされ、プロジェクトを完全に再構築できます。

Editor113

Editor114

問題を抑える簡単な方法

エラーを抑制するための手っ取り早い方法は、ビルドスクリプトのMPS設定セクションのブートストラッププロパティをtrueに設定することです

bootstrap2

これは、プロジェクトのビルドを一時的に有効にする最後の手段であると考えてください。問題のあるブートストラップの依存関係をすべて排除する適切なソリューションを推奨します。

最終更新日: 2020年2月4日