C ++ライブラリのディレクトリ構造

私はC ++ライブラリに取り組んでいます。最終的には、いくつかの例とPythonバインディングとともに、複数のプラットフォーム（少なくともLinuxとWindows）で公開したいと思います。作業は順調に進んでいますが、現時点ではプロジェクトは非常に厄介で、Visual C ++専用に組み込まれており、マルチプラットフォームではありません。

したがって、クリーンアップが必要だと感じています。私が最初に改善したいのは、プロジェクトのディレクトリ構造です。Automakeツールに適した構造を作成して、複数のプラットフォームで簡単にコンパイルできるようにしたいのですが、これまで使用したことがありません。私はまだVisualStudioで（ほとんどの）コーディングを行っているので、VisualStudioプロジェクトとソリューションファイルも保持する場所が必要になります。

「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ライブラリで非常に一般的なことの1つは、次のように編成されていることです。

./         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を使用しています。）

あなたへの私の提案は、あなた（そしてあなたのチーム）にとって意味のあるディレクトリレイアウトを選ぶべきだということです。選択した開発環境、ビルドツール、およびソース管理に最も適した方法を実行します。

私が最近出会ったこの素晴らしいコンベンションが役立つかもしれません：Pitchfork Layout（これもGitHubにあります）。

要約すると、サブセクション1.3は次のように述べています。

PFLは、プロジェクトツリーのルートに表示されるいくつかのディレクトリを規定しています。すべてのディレクトリが必要なわけではありませんが、目的が割り当てられており、ファイルシステム内の他のディレクトリがこれらのディレクトリのいずれかの役割を担うことはできません。つまり、これらのディレクトリは、目的が必要な場合に使用されるディレクトリである必要があります。

他のディレクトリはルートに表示されるべきではありません。

build/：プロジェクトのソースの一部と見なされるべきではない特別なディレクトリ。一時的なビルド結果を保存するために使用されます。ソース管理にチェックインしないでください。ソース管理を使用する場合は、ソース管理の無視リストを使用して無視する必要があります。

src/：主なコンパイル可能なソースの場所。サブモジュールを使用しないコンパイル済みコンポーネントを含むプロジェクトに存在する必要があります。が存在するinclude/場合、プライベートヘッダーも含まれます。

include/：パブリックヘッダーのディレクトリ。存在する可能性があります。プライベートヘッダーとパブリックヘッダーを区別しないプロジェクトでは省略できます。サブモジュールを使用するプロジェクトでは省略できます。

tests/：テスト用のディレクトリ。

examples/：サンプルと例のディレクトリ。

external/：プロジェクトで使用されるが、プロジェクトの一部として編集されないパッケージ/プロジェクトのディレクトリ。

extras/：プロジェクトの追加/オプションのサブモジュールを含むディレクトリ。

data/：プロジェクトの非ソースコードの側面を含むディレクトリ。これには、グラフィックおよびマークアップファイルが含まれる場合があります。

tools/：ビルドスクリプトやリファクタリングスクリプトなどの開発ユーティリティを含むディレクトリ

docs/：プロジェクトドキュメントのディレクトリ。

libs/：メインプロジェクトサブモジュールのディレクトリ。

さらに、extras/ディレクトリはPythonバインディングを配置する場所だと思います。

これについての良いガイドラインは実際にはないと思います。そのほとんどは個人的な好みです。ただし、特定のIDEが基本構造を決定します。たとえば、Visual Studioは、DebugサブフォルダーとReleaseサブフォルダーに分割された個別のbinフォルダーを作成します。VSでは、これは、さまざまなターゲットを使用してコードをコンパイルする場合に意味があります。（デバッグモード、リリースモード。）

greyfadeが言うように、自分にとって意味のあるレイアウトを使用してください。他の誰かがそれを気に入らなければ、彼らはそれを自分で再構築する必要があります。幸い、ほとんどのユーザーは、選択した構造に満足するでしょう。（それが本当に厄介でない限り。）

wxWidgetsライブラリ（オープンソース）が良い例だと思います。それらは多くの異なるプラットフォーム（Win32、Mac OS X、Linux、FreeBSD、Solaris、WinCE ...）とコンパイラー（MSVC、GCC、CodeWarrior、Watcomなど）をサポートします。ここでツリーのレイアウトを確認できます。

https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/

CMakeの使用をお勧めします...これはクロスプラットフォーム開発用であり、自動作成よりもはるかに柔軟性があり、CMakeを使用すると、すべてのシステムで独自のディレクトリ構造を使用してクロスプラットフォームコードを記述できます。