2009-09-09 18 views
60

私はC++ライブラリで作業しています。最終的には、複数のプラットフォーム(少なくともLinuxとWindows)といくつかの例とPythonバインディングで公開することを望んでいます。仕事はうまく進んでいますが、現時点ではプロジェクトは全く複雑で、Visual C++のためだけに構築され、マルチプラットフォームではありません。C++ライブラリのディレクトリ構造

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

私は「C++ライブラリディレクトリ構造」のような言葉でgoogleを試しましたが、役に立つものは何も出てこないようです。私はいくつかの非常に基本的なガイドラインを見つけましたが、透明なソリューションはありません。

いくつかのオープンソースのライブラリを見ながら、私は次のを思い付いた:

\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のライブラリの中では非常に一般的です

+0

は、OUT- CMakeのを使用する場合はhttp://stackoverflow.com/questions/1383174/source-file-organisation/1383188#1383188 –

答えて

80

ことの一つは、彼らがそのようなことを整理していることである:それはやや/usrの下で、伝統的な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` 

場所:もちろん

/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/ディレクトリを使用するのは避けてください。私はautakeを使わず、代わりにCMakeを使います)

が作成するディレクトリレイアウトを選択することをお勧めしますあなたのための感覚(あなたのチーム)。選択した開発環境、ビルドツール、およびソース管理に最も賢明なことを実行します。

+3

の重複のように思える:あなたはここで、ツリーのレイアウトを見ることができますソースのビルドは素晴らしいようです。 – Korchkidu

5

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

greyfadeによれば、あなたに合ったレイアウトを使用します。他の誰かがそれを気に入らないのであれば、自分でそれを再構成するだけです。幸いにも、ほとんどのユーザーはあなたが選んだ構造に満足しています。 (本当に乱雑でない限り)

4

wxWidgetsライブラリ(オープンソース)が良い例です。彼らは、さまざまなプラットフォーム(Win32、Mac OS X、Linux、FreeBSD、Solaris、WinCEなど)をサポートしています。)とコンパイラ(MSVC、GCC、CodeWarrior、Watcomなど)が含まれます。

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

関連する問題