1. ホーム
  2. c++

[解決済み] C++ライブラリのディレクトリ構造

2023-06-07 05:54:27

質問

私はC++のライブラリに取り組んでいます。最終的には、複数のプラットフォーム (少なくとも Linux と Windows) で利用できるように、いくつかのサンプルと Python バインディングも。作業は順調に進んでいますが、現時点では、このプロジェクトはかなり雑で、もっぱら Visual C++ で構築されており、マルチプラットフォームではありません。

したがって、私はクリーンアップが必要であると感じています。私が改善したい最初のことは、プロジェクトのディレクトリ構造です。私は、このプロジェクトに適した構造を作りたいと思います。 自動化 ツールに適した構造にしたいのですが、私はこれまでこれを使ったことがありません。私はまだ Visual Studio で (ほとんどの) コーディングを行うので、Visual Studio プロジェクトとソリューション ファイルも保管する場所が必要です。

C++ ライブラリ ディレクトリ構造" のような用語をグーグルで検索してみましたが、役に立つものは何も出てきません。いくつかの非常に基本的なガイドラインは見つかりましたが、明確な解決策はありませんでした。

いくつかのオープン ソース ライブラリを調べているうちに、次のようなことを思いつきました。

\mylib
    \mylib <source files, read somewhere to avoid 'src' directory>
        \include? or just mix .cpp and .h
    \bin <compiled examples, where to put the sources?>
    \python <Python bindings stuff>
    \lib <compiled library>
    \projects <VC++ project files, .sln goes in project root?>
    \include? 
    README
    AUTHORS
    ...

私は、マルチプラットフォーム開発/オープンソース プロジェクトの経験がまったくない、あるいはほとんどなく、そのようなプロジェクトの構成方法に関する良いガイドラインが見つからないことに非常に驚いています。

一般的に、このようなライブラリ プロジェクトをどのように構成すべきでしょうか。何を読むことが推奨されますか?何か良い例はありますか?

どのように解決するのですか?

Unixのライブラリで非常によくあるのが、このような構成になっていることです。

./         Makefile and configure scripts.
./src      General sources
./include  Header files that expose the public interface and are to be installed
./lib      Library build directory
./bin      Tools build directory
./tools    Tools sources
./test     Test suites that should be run during a `make test`

の下にある伝統的な Unix ファイルシステムをいくらか反映しています。 /usr のところにあります。

/usr/src      Sometimes contains sources for installed programs
/usr/include  Default include directory
/usr/lib      Standard library install path
/usr/share/projectname   Contains files specific to the project.

もちろん、これらは最終的に /usr/local (これは GNU autoconf のデフォルトのインストールプレフィックスです) になってしまい、この構造には全く従わないかもしれません。

厳密なルールはありません。私自身はこの方法で物事を整理していません。(私は ./src/ ディレクトリは使わないようにしています。また、私はautotoolsを使用せず、代わりにCMakeを好んでいます)。

私の提案は、以下のようなディレクトリレイアウトを選択することです。 を選択することです。 (ということです。) あなたが選んだ開発環境、ビルドツール、およびソース管理にとって最も賢明なものは何でもしてください。