生産レベルのプロジェクトのライブラリ/ツールの特定のビルドを含めることは一般的ですか？
Linux/Unix環境でC++を使用しています。大規模プロジェクトの物理設計を学ぼうとしています。私のプロジェクトの1つで、カメラメーカーのSDKを使用しています。彼らはこのSDKの新しいバージョンをリリースし、以前のバージョンに基づいて構築したアプリケーションの1つは、SDKにいくつかの再構成と変更が行われたため機能しなくなりました。私はコードに変更を加えることでこれを修正しました。これはプロダクションレベルのコードではなく、研究のみを目的としています。
最近、ルートディレクトリ内に特定のgcc-buildのフォルダーがある別のプロジェクトに遭遇しました。 CMakeLists.txtを確認したところ、このフォルダ内で使用可能なツールを使用するように設定されていたようです。
最初のケースでは、
cmakeとその他の関連ツールを構成して、正しいバージョンのSDKが（他の研究者に）確実に出荷されるようにすべきですか？ここでは2つの方法のいずれかを使用できたようです。コードをビルドする前に、特定のバージョンのSDKがダウンロードおよびインストールされるようにするスクリプトを使用します。ユーザーがシステムでこのスクリプトを実行していることを確認します。
SDKから必要なすべてのライブラリファイルを取得してプロジェクトフォルダー内に提供し、cmakeにこれらのファイルを具体的に使用するように依頼します。
どちらが正しいアプローチですか？ 2番目のアプローチの場合、SDKライブラリファイルはプロジェクトのルートフォルダー内の
libディレクトリにありますか？2番目のケースでは、特定の
gcc-buildを含めるのは少し極端ですか？それとも、物事が壊れないようにするのが一般的な方法ですか？共有ライブラリファイルの場合、個別のコピーを保持して出荷することは、共有ライブラリを持つ目的に部分的に及ばないのですか？システム全体で1つのファイルセットを使用し、かさばるコードの配布を回避するという考えの1つではありませんか？
生産レベルのプロジェクトのライブラリ/ツールの特定のビルドを含めることは一般的ですか？
それは少なくとも全く珍しいことではないと思います、そしてそれはあなたが「生産レベル」をどのように定義するかに依存します。ただし、サードパーティの依存関係が予測できない方法で変更されても壊れない100％再現可能なビルドを実現しようとすると、すべてのアーティファクトとビルドツールを自分でバージョン管理する必要があります。
もちろん、コンポーネントのベンダーが古いバージョン、具体的にはソフトウェアに必要なバージョンを提供するという信頼がある場合は、「ダウンロードおよびインストールスクリプト」のソリューションで十分です。それでも、すべてのツールを少なくとも自分自身のために正しいバージョンでアーカイブすることをお勧めします。そうすれば、サードパーティベンダーから何かをダウンロードすることに問題がある人に後で提供できるようになります。
たとえば、あなたのケース（1）：カメラベンダーが「適切なバージョンのSDK」を十分に長く提供していることを100％確信していますか？十分に安定している場所では、ダウンロードスクリプトは、たとえば3年間でも、それを自動的に見つけます。または、この特定のソフトウェアが使用されている研究期間がはるかに短いため、それは問題ではないかもしれません。
または、ケース（2）を見てみましょう： このページ では、20年以上前の古いGCCリリースを見つけることができるため、必要に応じて古いバージョンを入手できるという確かな信頼があります。 。しかし、コンパイルツールの正しい組み合わせを一緒に取得するのがいかに難しいかがわかると（たとえば True Crypt を参照）、全体として完全なツールセットを提供することは、特に特定の複雑さのプロジェクト。
これは、念頭に置いているプロジェクトの種類にも依存します。いくつかのGCCバージョンによってコンパイルされることを目的としたオープンソースlibの要件は、維持する必要があるクローズドソースの商用製品の要件とはかなり異なる場合があります。数年以上、おそらく何らかの契約を満たすために。
そしてあなたの質問（3）に：ディスク容量は安価であり、システムで各共有ライブラリを一度だけ持つことでリソースを節約することは、通常は価値がありません。完全に最適化されていないリソースを使用する稼働中のソフトウェアは、最適なリソース使用率の稼働していないソフトウェアよりも間違いなく優れています。