web-dev-qa-db-ja.com

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

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

したがって、クリーンアップが適切であると感じています。最初に改善したいのは、プロジェクトのディレクトリ構造です。 Automake ツールに適した構造を作成して、複数のプラットフォームで簡単にコンパイルできるようにしますが、これまで使用したことがありません。 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
    ...

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

一般に、このようなライブラリプロジェクトをどのように構成する必要がありますか？読むことが推奨されるものは何ですか？良い例はありますか？

c++directory-structureautomake
70
TC.

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`

/usrの下の従来のUnixファイルシステムをいくらか反映しています。ここで：

/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を優先します。）

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

93
greyfade

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

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

5
Milan Babuškov

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

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

5
Wim ten Brink

私が最近出会った便利なこの素晴らしい規則があります： The Pitchfork Layout （これも GitHub ）。

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

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

他のディレクトリはルートに表示されません。

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

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

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

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

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

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

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

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

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

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

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

さらに、extras/ディレクトリは、Python bindings should go） です。

4
Gabriel Galli

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

0
stuv_2028