C / C ++プロジェクトの依存関係を適切に管理する方法は?


11

3〜4種類のオープンソースC / C ++ライブラリを使用するプロジェクトがあります。

これらのライブラリをいくつかのプラットフォーム用にビルドし、プロジェクトのさまざまなプラットフォーム用のインクルードファイルとスタティックライブラリをチェックインしました。

しかし、私はいくつかの問題に苦労しています。これらのプロジェクトはすべて、依存関係管理に関するものです。そして、私はベストプラクティスのアドバイスを探しています。

1)何を使用しているのか正確に知るにはどうすればよいですか?

静的libのバージョンを取得する方法がありません。結果として、使用している静的libのバージョンを何らかの方法で追跡する必要があります(ビルド元のコミットのSHAである可能性があります)?

これらのライブラリをいつアップグレードするかを理解する必要がある場合、これは特に重要です。

2)ビルドを再現するにはどうすればよいですか?

特定のプラットフォーム用の特定のライブラリーを構築するのに苦労したかもしれません。それを理解するのにしばらく時間がかかりました。

次回同じライブラリを作成する必要があるのは、半年後(なんらかの理由でアップグレードが必要になるとき)になる可能性があります。しかし、そのときまでに、何がどのライブラリで構築されたのかはっきり覚えていません長い間なくなります。

3)これらのライブラリをフォークしてソースコードのコピーを作成する必要がありますか?

これはそれほど問題ではありません。しかし、それはまだ問題です。ビルドが再現可能であることを確認するのは良いことです(そのようなソースコードが必要です)。

回答:


5

依存ライブラリの正確なバージョンを常に使用する必要がありますか?それはひどく書かれていますか/バージョンのマイナーな増加ごとにAPIを壊していませんか?

オープンソースプロジェクトを見ると、ビルド(configure一部は主に)スクリプトがさまざまなライブラリが存在するかどうかを確認し、存在しない場合はエラーをスローします。また、ユーザーが新しいバージョンのライブラリ(おそらく古いバージョンよりも多くのバグ/セキュリティ修正を提供する)にリンクできるように十分に柔軟であり、静的または動的リンクを強制しません。

本当に再現可能なビルドが必要な場合は、コンパイラの正確なバージョンとその標準ライブラリ、さらにはオペレーティングシステムにも注意を払う必要があります。この場合、必要な正確な環境を備えたビルドマシンを用意することは、私の意見では、ソースコードリポジトリのコンパイル済みライブラリをチェックインするよりも優れています。


2
正確なバージョンを使用する必要があるとは思いません。ただし、どちらを使用しているかを知る必要があります。たとえば、誰かがOpenSSL 1.1.0bに大きな脆弱性があることを発見した場合、私はOpenSSL 1.1.0bと1.1.0cのどちらを使用するかをよく知っています
Victor Ronin

ビルドの再現性に関しては、おそらくそれが私の2番目の懸念事項です。
Victor Ronin

3

何を使用しているのか正確に知るにはどうすればよいですか?

インクルードファイルまたはlibsファイルにバージョン番号がまだ含まれていない場合は、テキストファイル "version.txt"(バージョン番号を含む)を各libフォルダーに自分で追加し、libおよびincludeファイルとともにVCSにチェックインします。 。ただし、libの完全なソースをバージョン管理する場合(ポイント3)、バージョン番号を含むソースコードファイルがすでに存在している可能性が高いため、このケースのために独自のバージョンを維持する必要はありません。

ビルドを再現するにはどうすればよいですか?

できるだけ自動化してください。お気に入りのビルドツールのスクリプト、makefile、またはファイルを使用します。これをすべてソース管理下に置きます。手動の手順が必要な場合は、詳細をテキストファイル(たとえば、readme_build.txt)に書き留め、それもソース管理下に置きます。

これらのライブラリをフォークしてソースコードのコピーを作成する必要がありますか?

あなたは持っている必要があり、ソースコードのコピーを、しかし、フォークにのみ、必要な場合(たとえば、あなたが緊急のバグを超えるつまずく場合、そして原作者はあなたの時間のcontraints以内にそれを修正することはできません)。または、作成者があなたとは異なるコンパイラ環境を使用していて、libを環境で機能させるためにいくつかの変更を加える必要がある場合。ただし、フォークの元のソースコードを変更するたびに、後で更新を統合することが難しくなる可能性が高いことに注意してください。

それにもかかわらず、使用しているライブラリの元の(フォークされていない)ソースコードのコピーを入手することをお勧めします。これにより、元のメンテナがパブリックWebからlibソースを取り消すことを決定した場合でも、後で必要になったときにlibをフォークまたはメンテナンスできます。


だから、答えは「これを手動で行う」です:)誰かが言うことを望んでいた...ああ...そのためのツールがあります:)「ソースコードのコピー」と言うときは、ソースを含むtarファイルをソース管理にダンプしますか?
Victor Ronin

1
@VictorRonin:いいえ、答えは「VCSができることはすべてVCSに任せる」、「標準のビルドツールを使用してできる限り自動化する」です。特定のバージョンを選択するのはあなたであり、ビルドステップを定義し、環境の参照をリンクして含める必要があるのはあなたです。これらdespendenciesを発現するための標準的な手順は、スクリプトなど、メイクファイル、プロジェクトファイル経由で
ドク・ブラウン

...そして、libまたはライブラリのソースコードを取得する方法は、メンテナ/ベンダーがどのように提供するかに依存します。多分git ballに直接アクセスすることによるtarボール、多分nugetパッケージでしょう。
Doc Brown
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.