86

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

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

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

このようなライブラリプロジェクトを一般的にどのように構成する必要がありますか？何を読むことをお勧めしますか？良い例はありますか？

4

5 に答える 5

111

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

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

于 2009-09-09T09:41:05.713 に答える
22

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

于 2019-02-24T14:39:29.587 に答える
4

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

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

于 2009-09-09T10:07:05.777 に答える
4

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

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

于 2009-09-09T10:27:25.267 に答える
-1

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

于 2019-02-16T23:48:59.283 に答える