可能な場合、システム/ディストリビューションが提供するライブラリに対するコード。これにより、そのディストリビューションで製品を出荷するのが簡単になります。
ただし、商用アプリケーションを構築している場合、Linux ディストリビューションには非常に多くのフレーバーがあるため、ディストリビューションごとに多数の異なるアプリケーション ビルドを維持する必要があります。これは、ディストリビューションのパッケージ管理システムとよりクリーンに統合できることを意味するため、必ずしも悪いことではありません。
ただし、それができない場合は、所有している各サードパーティの依存関係のソースをダウンロードし、その依存関係の構築を実行可能ファイルにリンクされている静的ライブラリに統合するのはかなり簡単なはずです。そうすれば、リンク先を正確に把握できますが、実行可能ファイルのサイズが肥大化するという欠点があります。これは、ディストリビューションによって提供されていない特定のライブラリ (またはバージョン) が必要な場合にも必要になることがあります。
コードをさまざまな異なる Unix システムで構築したい場合は、おそらく GNU autoconfとautomakeを検討するのが賢明でしょう。これらは、実質的にすべての Unix システム上でビルドできるように、configureスクリプトを作成し、プロジェクト用に作成するのに役立ちます。makefile
また、適切なライブラリ (pkg-config をサポートするライブラリの場合) を含めてリンクするのに役立つように、現在 Linux ディストリビューションでかなり使用されているpkg-configも調べてください。
Subversion を使用してソースを管理している場合、ほとんどの Subversion リポジトリが独自のコードと「ベンダー」コードを管理するために使用する「規則」があります。
ほとんどの svn リポジトリには「ベンダー」ツリーがあります (トランク、ブランチ、タグ ツリーと一緒です)。これは、すべてのサードパーティ ベンダー コードのトップです。そのディレクトリには、使用する各ライブラリのディレクトリがあります。例えば：
branches/
tags/
trunk/
vendor/somelib
vendor/anotherlib
これらの各ライブラリの下には、各ライブラリ バージョンのディレクトリと、リポジトリ内の最新バージョンの「現在の」ディレクトリがあります。
vendor/somelib/1.0
vendor/somelib/1.1
vendor/somelib/current
次に、プロジェクトのツリーは次のようにレイアウトする必要があります。
Trunk/source # すべてのコードをここに配置 Trunk/libs # すべてのベンダー コードをここに配置
libs ディレクトリは空である必要がありますが、次の方法でsvn:externalsメタデータが関連付けられています。
svn propedit svn:externals trunk/libs
このプロパティの内容は次のようになります (Subversion 1.5 を想定):
^/vendor/somelib/current somelib
^/vendor/anotherlib/1.0 anotherlib
つまり、コード サブバージョンをチェックアウトすると、ベンダー ライブラリもトランク/libs ディレクトリにチェックアウトされます。チェックアウトすると、次のようになります。
trunk/source
trunk/libs/somelib
trunk/libs/anotherlib
これは、 Subversion Bookで説明されています (おそらくはるかに優れています) 。特に、ベンダー ブランチと外部の処理に関するセクション。