8

私はチームの一員として SWT プロジェクトに取り組んでいます。Eclipse の .classpath ファイルがバージョン管理にチェックインされ、マシン用にさまざまな SWT ライブラリが含まれているため、私たちは常にお互いのビルド環境を壊しています。

誰が最後にコミットしたかに応じて、.classpath エントリは次のようになります。

<classpathentry kind="lib" path="lib/swt/swt-win32.jar"/>

また

<classpathentry kind="lib" path="lib/swt/swt-carbon.jar"/>

また

<classpathentry kind="lib" path="lib/swt/swt-gtk.jar"/>

ライブラリは相互に排他的であるようです。つまり、一度にすべてを含めて SWT に任せることはできません。したがって、プラットフォームごとに何らかの方法でそれらをフィルタリングする必要があります...

これを行う方法について誰かアイデアがありますか？私の最初のアイデアは、これを独自の「.classpath-swt」ファイル (VCS によって無視される) に分割し、Ant を使用して自動生成し、メインの .classpath に含めることでしたが、Eclipse は分割をサポートしていないようです.classpath ファイル。

私たちの現在の回避策は、実際に依存関係を変更していない限り、.classpath をコミットしないようにすることですが、.classpath が変更されるたびに多くの人が開発環境を修正する必要があることを意味します。

これはこのプロジェクトのオプションではないため、「Eclipseを使用しない」ではない限り、どんな提案も大歓迎です:)

4

4 に答える 4

0

SWT は、.classpath ファイルをバージョン管理するのではなく、オペレーティング システムとウィンドウ システムが追加された複数の個別の .classpath_* ファイル (.classpath_win32_win32 など) をバージョン管理することによってこれを行います。したがって、リポジトリからソースをチェックアウトするときは、適切なクラスパス ファイルを .classpath にコピーして、プロジェクトを再コンパイルする必要があります。

于 2009-03-10T20:56:31.633 に答える
0

独自のインスタンスを構成するだけで、環境のこの 1 つのコンポーネントについて、ソース管理に保持しないのはどうですか?

または、環境ごとにクラスパス ファイルを保存することもできます。おそらく別のディレクトリと ant ファイル、つまり build-setup-env.xml ファイルに、正しいものをコピーする環境ごとに 1 つのターゲットを設定するだけです。これのコピーをソース管理に保持する場合は、更新時に必ずコピーして戻す必要があります。

于 2009-01-30T12:17:20.407 に答える