pure-systems 2024 ソースコード管理ソフトウェア用コネクタユーザーマニュアル

pure::variants – コネクタ
ソースコード管理マニュアル
パラメトリックテクノロジー株式会社
pure::variants 6.0.7.685 のバージョン 6.0
著作権 © 2003-2024 パラメトリックテクノロジー GmbH
2024

コンテンツ 隠れる

導入

pure::variants ソースコード管理用コネクタ（コネクタ）を使用すると、開発者は pure::variants を使用してソースコードの可変性を管理できます。pure::variants のソースコード管理は、ディレクトリ構造とソースコードを同期する柔軟な機会を提供します。 filepure::variants モデルを使用すると、バリアント管理が簡単になります。これにより、複雑なソフトウェアプロジェクトにもバリアント管理を実用的に適用できます。さらに、pure::variants 機能とソースコード間の接続は、ビルダーで簡単に管理でき、ソースコード管理を介して簡単にアクセスできます。
1.1.ソフトウェア要件
ソースコード管理用の pure::variants コネクタは pure::variants の拡張機能であり、サポートされているすべてのプラットフォームで利用できます。
1.2. インストール
コネクターのインストール方法の詳細については、pure::variants セットアップガイドのセクション pure::variants コネクターを参照してください (メニュー [ヘルプ] -> [ヘルプコンテンツ]、次に [pure::variants セットアップガイド] -> [pure::variants コネクター])。
1.3. このマニュアルについて
読者は pure::variants に関する基本的な知識と経験があることが求められます。このマニュアルを読む前に、入門資料を参照してください。マニュアルは、オンラインヘルプと印刷可能な PDF 形式でこちらから入手できます。

コネクタの使用

2.1. pure::variants の開始
使用するインストール方法に応じて、pure::variants 対応の Eclipse を起動するか、Windows ではプログラムメニューから pure::variants 項目を選択します。
バリアント管理パースペクティブがまだアクティブになっていない場合は、[ウィンドウ] メニューの [パースペクティブを開く] -> [その他...] から選択してアクティブにします。
2.2. ディレクトリツリーをファミリモデルにインポートする
ディレクトリツリーをファミリモデルにインポートする前に、バリアントプロジェクトを作成する必要があります。また、フィーチャモデルでフィーチャを定義しておくことも推奨されます。これらの手順の詳細については、pure::variants のドキュメントを参照してください。
実際のインポートは、プロジェクトのコンテキストメニューで「インポート…」アクションを選択することで開始されます。 view または、 File メニュー。カテゴリ「バリアント管理」から「バリアントモデル」または「プロジェクト」を選択し、「次へ」を押します。次のページで「ソースフォルダーからファミリモデルをインポート」を選択し、もう一度「次へ」を押します。
インポートするソースコードの種類を選択してください
インポートウィザードが表示されます（図1「インポート可能なソースコードの種類を選択するためのインポートウィザードのページ」を参照）。インポートするプロジェクトの種類を選択し、「次へ」を押します。各タイプには、定義済みの一連の file モデルにインポートするタイプ。
図 1. インポート可能なソースコードの種類を選択するインポートウィザードのページソースとターゲットを選択
次のウィザードページ（図 2、「インポートのソースとターゲットを選択するインポートウィザードのページ」) ソースディレクトリとターゲットモデルを指定する必要があります。
[参照...] ボタンを押して、インポートするソースコードが存在するディレクトリを選択します。デフォルトでは、現在のワークスペースが選択されます。これは、ナビゲートを開始するのに便利なポイントになる可能性があるためです。
以下で、含めるパターンと除外するパターンを指定できます。これらのパターンは、Java 正規表現である必要があります。ソースルートフォルダーを基準とした各入力パスは、これらのパターンでチェックされます。含めるパターンが一致するとフォルダーがインポートされ、除外パターンが一致しない場合はフォルダーがインポートされます。つまり、含めるパターンはインポートするフォルダーを事前に選択し、除外パターンはこの事前選択を制限します。
ソースコードディレクトリを選択した後、ターゲットモデルを定義する必要があります。そのため、モデルを保存するバリアントプロジェクトまたはフォルダを選択し、モデル名を入力します。 file このダイアログで指定されていない場合、名前は自動的に .ccfm 拡張子で拡張されます。デフォルトでは、モデル名自体と同じ名前に設定されます。これが推奨設定です。
適切なソースフォルダーと目的のモデル名を指定したら、[完了] を押してダイアログを終了できます。[次へ] ボタンを押すと、追加の設定を行うことができる次のページが表示されます。
図 2. インポートのソースとターゲットを選択するインポートウィザードのページインポート設定を変更する
最後のウィザードページ（図3、「個別の構成を定義するインポートウィザードのページ」) には、インポートされたソフトウェアプロジェクトのインポート動作をカスタマイズするための設定があります。
ダイアログページには、 file タイプが定義され、インポートプロセスで考慮されます。
各行は 4 つのフィールドで構成されます。

説明フィールドには、 file タイプ。
の File 名前パターンフィールドは選択に使用されます fileフィールド値と一致する場合にインポートされるデータ。フィールドでは次の構文を使用します。

最も一般的な使用例は、 file 拡張子。通常の構文は.EXTで、EXTは希望する拡張子です。 file 拡張子 (例: .java)。
もう一つのよくある状況は、特別な file、メイクのようにfileしたがって、正確に一致させることが可能です file 名前を入力します。これを行うには、 file フィールドに名前を入力します (例: build.xml)。

場合によっては、マッピングの要望がより具体的なので、 file特別なパターンに一致するものをインポートする必要があります。この要件を満たすために、 File 名前パターンフィールド。
正規表現の構文を説明すると、このヘルプの目的を超えてしまいます。pure::variants ユーザーズガイドのリファレンスチャプターの正規表現セクションを参照してください (例: .*)。

マップされた要素タイプフィールドは、 file 型とpure::variantsファミリー要素型。ファミリー要素型はソースの記述子である。 file インポートされたモデル内のマップされた要素に詳細情報を提供します。一般的な選択肢はps:classまたはps:makeです。file.

マップされた file タイプフィールドは、 file 型と pure::variants file タイプ。 file pure::variantsの型はソースの記述子である file インポートされたモデル内のマップされた要素にさらに情報を提供します。典型的な選択肢は、実装の場合は impl、定義の場合は def です。 files.

図3. 個別の構成を定義するインポートウィザードのページ新しい file マッピングの追加ボタンを使用して、タイプを追加できます。すべてのフィールドには未定義の値が入力されており、ユーザーが入力する必要があります。フィールドの値を編集するには、マウスでフィールドをクリックします。値が編集可能になり、変更できるようになります。デフォルトの値を変更することはできません。 file テーブルの名前パターン。カスタマイズを柔軟にするために、 file 行の選択を解除して入力します。選択解除 file 名前パターンは設定に残りますが、インポーターでは使用されません。ユーザー定義 file マッピングの削除ボタンを使用すると、タイプを再度削除できます。
デフォルトではその他 files file 名前パターンはテーブルで利用可能ですが、選択されていません。通常、すべてをインポートする必要はありません。 fileただし、対応する行を選択することで簡単に変更できます。
インポーターの動作をカスタマイズするための一般的なインポートオプションが 3 つあります。

一致しないディレクトリをインポートしない file（例：CVS ディレクトリ）。
インポーターが一致するディレクトリが見つからない場合 file そこに存在し、サブディレクトリに一致するものがない場合 fileディレクトリはインポートされません。プロジェクトがCVSのようなバージョン管理システムで管理されている場合、これは便利です。CVSの場合、関連するディレクトリにはそれぞれCVSディレクトリが含まれますが、無関係なディレクトリは含まれません。 fileが保存されます。このオプションが選択され、CVS-filesはいずれにも一致しません file 上記で定義されたタイプでは、ディレクトリはファミリモデルにコンポーネントとしてインポートされません。
選別 fileとディレクトリ。
並べ替えるにはこのオプションを有効にします files とディレクトリはそれぞれアルファベット順に並べられています。

インポートパスの処理。
さらに同期するには、インポーターはモデルにインポートされたすべての要素の元のパスを保存する必要があります。
多くの場合、ファミリモデルは他のユーザーと共有されます。ディレクトリ構造はユーザーごとに異なる場合があります。最も一般的な使用シナリオをサポートするために、インポーターはさまざまなモードで動作できます。

絶対	インポートされた要素への絶対パスはモデルに保存されます。後で同期したり変換したりするときに、 file最初のインポート時とまったく同じ場所に配置する必要があります。
ワークスペースに相対	パスはワークスペースフォルダからの相対パスとして保存されます。同期のために、 files は Eclipse ワークスペースの一部である必要があります。変換では、Eclipse ワークスペースを入力ディレクトリとして使用する必要があります。
プロジェクトに関連して	パスはプロジェクトを基準として保存されます。同期のために、 fileは Eclipse 内のプロジェクトの一部です。変換ではプロジェクトフォルダーを入力ディレクトリとして使用する必要があります。
パスに相対	パスは指定されたパスを基準として保存されます。同期のために、 fileは正確に同じ場所に配置する必要があります。変換入力ディレクトリは、インポート時の相対パスと同じです。

このダイアログのすべての設定は永続的に保存されます。インポートが実行されるたびに、個人的なカスタマイズをやり直す必要はありません。これにより、インポートワークフローが簡単かつ高速になります。
2.3. ディレクトリツリーからのモデルの更新
同期ボタンを押しますインポートしたモデルをそのディレクトリパスと同期します。プロジェクトのルートパスはモデルに保存されるため、以前と同じディレクトリに同期されます。同期ボタンを有効にするには、モデルを開いて任意の要素を選択します。同期ボタンを押すと、比較エディターが開き、現在のファミリモデルと現在のディレクトリ構造のモデルが対比されます (図 4「比較エディターのディレクトリツリーからのモデル更新」を参照)。
図4. 比較エディタのディレクトリツリーからのモデルの更新 比較エディターは pure::variants 全体でモデルバージョンを比較するために使用されますが、この場合は物理ディレクトリ構造 (右下側に表示されます) と現在の pure::variants モデル (左下側) を比較するために使用されます。すべての変更は、影響を受ける要素順に、エディターの上部に個別の項目としてリストされます。
このリストの項目を選択すると、両方のモデルにおけるそれぞれの変更が強調表示されます。ampたとえば、追加された要素は右側にボックスでマークされ、左側のモデル内の実行可能な位置に関連付けられます。上部と下部のエディターウィンドウの間にあるマージツールバーには、ディレクトリツリーモデルからフィーチャモデルに単一の変更またはすべての (競合しない) 変更を全体としてコピーするためのツールが用意されています。
注記
同期は最後に使用したインポーター設定で行われます。これにより、インポート中に行われた他の設定でモデルを更新できるようになります。

リレーションインデクサーの使用

ソースコード管理用コネクタは、関係を強化します View pure::variants モデル要素とソースコード間の接続に関する情報が含まれます。ps:condxml 要素と ps:condtext 要素の条件で使用される機能に関係が追加されます。
ps:flagおよびps:flagの場合file C/C++ソース内のプリプロセッサ定数の位置を示す要素 fileが表示されます。さらに、機能の一意の名前とプリプロセッサ定数間のマッピングを使用して、選択した機能に対して一致するプリプロセッサ定数の場所が表示されます。
3.1. プロジェクトへのリレーションインデクサーの追加
リレーションインデクサーは、特別なプロジェクトプロパティページでアクティブ化できます。プロジェクトを選択し、コンテキストメニューで [プロパティ] 項目を選択します。次のダイアログで [リレーションインデクサー] ページを選択します。
図 5. リレーションインデクサーのプロジェクトプロパティページ

リレーションインデクサーは、リレーションインデクサーを有効にするオプション（1）を選択すると、プロジェクトに対して有効になります。インデクサーを有効にした後、プロジェクト固有の動作を定義するためのオプションがいくつかあります。pure::variants条件とC/C++プリプロセッサ定数のインデックスは個別に有効にできます（2）。 file 名前パターン（3）は、 fileインデックス作成にはsを使用します。 fileパターンの1つに一致するものがスキャンされます。パターンとして「*」を追加すると、すべてのパターンがスキャンされます。 fileプロジェクトの。
プロジェクトのインデクサーをアクティブにすると、ビルダーがプロジェクトに追加されます。このビルダーは変更された部分をスキャンします。 filepure::variants モデル要素への新しいリレーションを自動的に検出します。
3.2. ソースコードとの関係
関係インデクサーをアクティブにすると、関係 View 追加のエントリが含まれています。これらのエントリには、 file バリアントポイントの行番号が表示されます。ツールチップには、 fileエントリをダブルクリックすると、 file エディターで開かれます。
pure::variants 条件
pure::variants条件は、 file フィーチャの選択に応じて、条件インデクサーはそのようなルールをスキャンし、参照されているフィーチャを抽出します。エディターでそのようなフィーチャが選択されている場合、関係 View すべて表示 file選択されたフィーチャーの条件が配置されている場所と行（図6「リレーションシップにおける条件の表現」を参照） View（）。
図6. 関係における条件の表現 View条件を定義する方法の詳細な説明については、pure::variants ユーザーズガイドの第 9.5.7 章の ps:condtext セクションを参照してください (リファレンス -> 定義済みソース要素タイプ -> ps:condtext)。
C/C++ プリプロセッサ定数
C/C++プリプロセッサインデクサーは、 fileプリプロセッサルールで使用される定数 (例: #ifdef、#ifndef、…)。
ps:flagまたはps:flagfile 要素が選択されると、関係 View 定義されたプリプロセッサ定数の使用法を示します。
関係 View また、マッピングパターンを使用して、機能に関連付けられたプリプロセッサ定数も表示されます。このため、パターンは選択された機能のデータで拡張されます。結果のシンボルは、一致するプリプロセッサ定数を検索するために使用されます。 図7「リレーションシップにおけるC/C++プリプロセッサ定数の表現」 View”は元ampパターン fame{Name} を持つファイル。パターンは、機能の一意の名前を使用して fameNative に拡張されます。インデックス付きコードには、プリプロセッサ定数 fameNative が使用されている場所が 76 か所あります。
これらの場所は関係に表示されます Viewパターンは設定で定義できます（セクション3.3「設定」を参照）。
図7. リレーションにおけるC/C++プリプロセッサ定数の表現 View

3.3. 設定
インデクサーのデフォルトの動作を変更するには、Eclipse の設定を開き、バリアント管理カテゴリのリレーションインデクサーページを選択します。このページには 2 つのリストが表示されます。
図 8. リレーションインデクサーの設定ページ上のリストにはデフォルトの file インデクサーのパターン（1）。このリストは、新しく有効になったプロジェクトの初期パターン設定です。
下のリストには、機能とプリプロセッサ定数 (2) 間のマッピングが含まれています。このマッピングはすべてのプロジェクトで使用されます。表 1「サポートされているマッピングの置換」には、すべての可能な置換が示されています。
表1. サポートされているマッピングの置換

ワイルドカード	説明	Example: 機能A
名前	選択したフィーチャの一意の名前	FLAG_{名前} – FLAG_FeatureA
名前	選択されたフィーチャの大文字の一意の名前	FLAG_{NAME} – FLAG_FEATUREA
名前	選択されたフィーチャの小文字の一意の名前	flag_{name} – flag_featurea