私の質問はthis oneに似ていますが、静的ライブラリに関しても:
複数のコンパイラと 32 ビットと 64 ビットの両方で動作する、Windows/Linux/Os X で適切にビルドされるクロスプラットフォームの C++ ヘッダー ライブラリがあります。ユーザーが zlib または libbz2 をインストールしている場合、ビルド システムは を介してライブラリの一部の機能を有効にします#ifdefs。
ユーザーが簡単にインストールできるように、Windows 用の zlib や libbz2 などのライブラリを、バイナリ形式または数回クリックしてインストールできるソースとして出荷したいと考えています。(Linux および Mac Os X では、システム パッケージが実際にほとんどの標準的なインストールで利用できるため、ライブラリを簡単にインストールできます。私が知る限り)。
最終的な解決策では、ユーザーが Visual C/C++ コンパイラ 2005、2008、および 2010 と MinGW を 32 ビットおよび 64 ビット Windows で使用して、zlib および libbz2 に簡単にリンクできるようにする必要があります。現時点および近い将来の C ライブラリのみに関心があります。
ライブラリは個別にビルドする必要があります。それらのビルドをビルド システムに統合したくありません。
私が見る限り、ここには少なくとも 2 つの自由度があります。
- 静的ライブラリまたは DLL を使用するかどうか。
- バイナリ ライブラリを出荷するか、ユーザーが独自のライブラリを構築できるようにするか。
もう 1 つのポイントは、ユーザーが自分のプログラムのデバッグ バージョンと最適化バージョンの両方に対してライブラリをリンクできる必要があるということです。私は Windows プログラミングの専門家ではありませんが、インターネットや職場の他の開発者から調べた限りでは、Windows のデバッグ ビルドとリリース ビルドにはこの (異常な?) 違いがあります。どうやら、デバッグ プログラムをリリース ライブラリに対してリンクしたり、その逆をリンクしたりすることはできません。これは正しいです？
(1) C++ コンパイラの依存 C ライブラリを出荷する最良の方法は何ですか? (2) 後で C++ ライブラリも出荷したい場合、ユーザーが各コンパイラでソースからビルドできるようにすることが唯一の実行可能な方法ですよね?