C プロジェクトのコードとその外部ライブラリを整理する最良の方法は何ですか?[閉まっている]
-
09-06-2019 - |
質問
私は新しい C プロジェクトを開始していますが、これは主に OSS ベースです。これは SourceForge にも掲載される予定です。この機会を利用して、この種のコードを整理するための確立されたベスト プラクティスを学びたいと思います。libcurl や libz などのライブラリを使用しており、MinGW と MSYS を使用してコンパイルします。
プロジェクトで使用しているすべてのライブラリのソースのコピーを配布するので、ソースをダウンロードする人は依存関係を探し回る必要がありません。ライブラリを保存するディレクトリは何と呼べばよいでしょうか?今のところ、次のどちらかで迷っています。
- lib、これらはライブラリであるためです。ただし、UNIX の世界では、「lib」には別の意味があります。
- src はソース ファイルであるためです。
- 私が書いていないので第三者です。
そして、これらのライブラリをどこにコンパイルすればよいのでしょうか?単純に構成してシステム ルートにインストールする必要がありますか、それともすべてのライブラリがコンパイルされるディレクトリを設定し、そこからリンクする必要がありますか?明らかに、これは私の Makefile に影響を及ぼします。
これについてはどうすればよいでしょうか?従うべき確立された慣例はありますか?どこかに書いてあるのでしょうか?
解決
まず、外部ライブラリとして使用します vendor
, しかし、それは単なる好みです。
第二に、インストールするのは得策ではないと思います 他の ユーザーが気づかないうちに、システム ルートにライブラリが保存されます。最も重要なのは、これはこれらのライブラリの後でインストールされたバージョンと競合するためです。したがって、これらのライブラリの最適な場所は、アプリケーションと同じディレクトリにあると思います。
これらのライブラリをプログラムに静的にコンパイルすることもできます。
他のヒント
以前の仕事では、ライブラリを 3rdparty という名前のディレクトリにインストールし、そこにライブラリをビルドするのが標準でした (3rdparty/LIBNAME/Debug など)。
_ext または _EXT サフィックスが付いたもの (つまり、MyProject_EXT) を使用して、リンク先の外部パッケージのソース コードを保存するものがプロジェクトの外部にあることを示します。
私もピーターの意見に同意します。外部ライブラリは競合を引き起こす可能性があるため、システム ルートに組み込まないでください。私なら、それらをディレクトリにビルドし、アプリケーションに固有の /lib ディレクトリ (または /extlib) にインストールし、そこにリンクします。
お願いします しないでください ソース内で、またはバイナリに静的にリンクされるか、またはその他の方法で、サードパーティのソースをコードとともに配布します。これは同じものの他のコピーに干渉するだけで、ライブラリの修正が必要な場合には更新されません。要件が何であるかをユーザーに伝えてください (そして、ライブラリ内の API の変更に常に対応してください)。自己コンパイル ユーザーは依存関係を確実に取得し、ディストリビューションはパッケージが配布されたバージョンで動作することを確認します。