ブートストラップ依存関係の問題の除去
定義:
いつでも
それ自体を使用する言語または
言語を使用し、その言語が機能するために同じソリューションを必要とする(つまり、間接的または直接依存する)ソリューション
ブートストラップ依存関係の問題があります。
なぜこれが問題なのですか
ビルドスクリプトを使用してプロジェクト全体をゼロから再構築することはできません
生成されたアーティファクトを VCS リポジトリに保持する必要があります
このブートストラップ依存関係サークルは、プロジェクトが完全に一から再構築されることを防ぎます。代わりに、言語を構築するには、ソリューションビルドアーティファクトの以前のバージョンが生成されている必要があります。同様に、ソリューションを構築するには、最初に言語を構築する必要があります。1 つのコマンドでプロジェクト全体を再構築することはできません。生成されたアーティファクトを VCS に保持する必要があり、プロジェクトの依存関係構造にはループが含まれます。
MPS 2.5.4 以降のビルドスクリプトは MPS コードを生成できるため、MPS ワークベンチに依存せずにコードを生成できます。ただし、プロジェクト構造内の依存関係のブートストラップは邪魔になります。
MPS の検出および除去ツールチェーン
プロジェクトを完全に再生成できないことは深刻な問題であると考えています。バージョン 2.5.4 以降の MPS でこのような依存関係をすべて検出し、排除するのに役立つツールを提供することにしました。MPS でプロジェクトを再構築しても何も変わりません。ただし、ビルドスクリプトを再構築する場合、MPS は、それらをエラーとして使用する言語とモジュール間の循環依存関係を検出および報告します。
ビルドスクリプトをリビルドすると、次のようなエラーレポートが表示される場合があります。
出力テキストには、問題を解決するためのヒントが含まれています。モジュールを右クリック -> 分析 -> モジュールの依存関係を分析
モジュールの依存関係を表示するアナライザーレポートパネルが表示されます。灰色(ブートストラップ依存関係)インジケーターは、問題のあるすべてのブートストラップ依存関係をハイライトするため、すばやく見つけることができます。左側のパネルで 1 つを選択すると、右側のパネルで依存関係の円の詳細が表示されます。モジュールの言語への依存関係が一覧表示され、続いて言語のモジュールへの依存関係が表示されます。これで、問題を修正するために 2 つの依存関係の方向のどちらを削除するかを選択できます。
問題を修正する
基本的に、依存関係のサイクルを断ち切る必要があります。最初に行う必要があるのは、OptimizeImports を呼び出すことです。モジュール間の依存関係が宣言されただけで、コードで実際には使用されていない場合、これによりモジュールが削除され、ブートストラップの問題が解決される可能性があります。問題が解決しない場合は、アナライザーをもう少し試してみる必要があります。
ブートストラップ依存関係の分析
たとえば、言語自体が独自の定義であるブートストラップ言語という問題を頻繁に修正していると想像してください。
右のパネルには、1 つの問題のある依存関係の方向のみが表示されています。
使用箇所の表示ポップアップメニューコマンドを使用すると、依存関係が必要なコード内のすべての具体的な出現箇所を一覧表示する 3 番目のパネルが表示されます。
残念ながら、自分で、どれを削除し、どのように削除するかを決める必要があります。これは手動プロセスになります。
依存関係のブートストラップの典型的なケース
ケース 1: 自己参照引用
言語の自己参照につながる間違いの非常に頻繁な例は、たとえば独自の型システム規則を定義するために、引用符で言語を使用することです。独自の型を宣言し、型システムの側面で引用符を使用してこの型をインスタンス化します。ここで、言語はビルドするためにビルドされている必要があります。
このような状況では、引用符の 代わりに軽い引用符を使用する必要があります。これらは、引用でノードのエディターを使用する必要なしに、軽量の引用のような機能を提供します。ライトクォーテーションで適切なノードを作成するには、コンセプト名と必要な機能を指定する必要があります。
見積もりからライト見積もりにすばやく変換するための便利なインテンションも利用できます。
相場に比べて光の引用は少し不便ですが、彼らは、ブートストラップの問題を回避できます。引用と反引用を大幅に組み合わせる必要がある場合は、意図をより適切に表現するために、引用よりも優先することもできます。
ケース 2: 言語は、アクセサーリモデルで自身を使用する
言語にはアクセサーリモデルを含めることができます。これらのアクセサーリモデルが包含言語を使用し、「フラグを生成しない」を選択していない場合、アクセサーリモデルと所有言語の間に循環依存関係が生じます。このような言語は、アクセサーリモデルを言語とともに生成する必要があるため、ゼロから再構築することはできません。
この問題の解決策は、アクセサーリモデルを別のソリューションに移行することです。MPS では、アクセサーリーモデルを言語の外部に置くことができます。
ケース 3: 言語は、jetbrains.mps.lang.pattern によって作成されたパターン内でそれ自体を使用する
この問題は、引用付きの問題に似ています。言語をゼロから再構築することは禁止されていませんが、循環依存関係は依然として残ります。現在、パターン内で言語を使用することを避けるか、ビルドスクリプトで依存関係をブートストラップできるようにする以外に、これに対する簡単な解決策はありません。
ケース 4: 言語のランタイムソリューションは、まったく同じ言語を使用する
言語のランタイムソリューション A は、一般的に言語 A を使用したモデルから生成されます。どんなことで実行されるコードが含まれています。そのため、ランタイムソリューションコードは、生成されたコードと同じ抽象レベル、つまり言語 A レベルの 1 レベル下に論理的に属します。下位レベルのコードを上位レベルのコードから分離し、プロジェクトを階層的に整理することをお勧めします。
この問題の解決策は、言語 A の使用をランタイムソリューションから別の別のモジュールに移動することです。
他にやるべきこと
すべての問題を個別に攻撃した後、プロジェクトのインポートを最適化し、ビルドスクリプトでディスクインテンションから再ロードモジュールを呼び出す必要があります。これにより、依存関係の構造がクリーンアップされ、プロジェクトを完全に再構築できるようになります。
問題を抑える簡単な方法
エラーを抑制する簡単な方法は、ビルドスクリプトの MPS 設定セクションで bootstrap プロパティを true に設定することです。このセクションは、ビルドスクリプトの一番下にあります。
上記のオプションは、問題の根本原因に対処するため、最初に選択する必要があります。問題のあるブートストラップの依存関係をすべて排除する適切なソリューションを優先する必要があります。ただし、すべてのブートストラップの依存関係を排除することが不可能または不可能な場合があります。そのような場合、プロジェクトをビルドできるようにするためのこの簡単な省略形が役立つ場合があります。
関連ページ:
言語のためのスタンドアロン IDE を構築する
導入:スタンドアロン IDE という用語は、特定のビジネス目的に必要なアーティファクトのみを含む、IDE の簡略版を指します。スタンドアロン IDE はエンドユーザーに DSL を配布する便利な方法を提供します。エンドユーザーは、IDE 設計者が用意した IDE サポート、リファクタリング、コード分析を含む言語を、専用の IDE で快適に使用できます。気になる言語設計関連の機能や不要な言語はすべて削除されます。言語を設計したら、MPS を使用すると、これらのドメイン固有の言語を使用するために必...
生成コードからのソースの削除
MPS は、デフォルトで生成されたモデルにソースをバンドルします。モデルのユーザーは、コードで使用している概念の定義に移動できます。たとえば、singleControl + クリックするだけで、呼び出しているメソッドやインスタンス化しているクラスの実装を確認できます。これは、実装側を覗くだけで言語 / ライブラリ作成者のアイデアの多くを把握できるため、ユーザーにとって非常に便利です。ただし、実装を非表示にすることが望まれる場合もあります。特にクローズドソースプロジェクトは、実装に含まれる知的財産...