web-dev-qa-db-ja.com

C ++クロスプラットフォームライブラリとバインディングに最適なフォルダー構造

C++で作成するクロスプラットフォームライブラリの作業を開始しようとしています。今後は、Python、Javaなどの他の言語のバインディングを実装する予定です。ライブラリは、win32、Linux、Mac OSXなどの主要なプラットフォームで使用できる必要があります。

アプリケーションは実際にはライブラリですが、いくつかの基本的なコンソールプログラムは、デモンストレーションとテストのためにアプリケーションとともにバンドルされます。

Subversionにデータを保存する前に、最適なフォルダ構造を考えたいのですが。

私は次のようなことを考えています：

/project                    //Top level folder

        /bin                //Binaries ready for deployment
            /linux_AMD64    //Linux AMD64 platform
                  /debug    //Debug build - duplicated in all platforms
                  /release  //Release build - duplicated in all platforms
            /linux_i386     //Linux 32-bit platform
            /macosx         //Mac OS X
            /win32          //Windows 32-bit platform
                  /cygwin   //Windows 32-bit platform compiled with Cygwin
                  /vs.net   //Windows 32-bit platform compiled with Visual Studio .NET
            /win64          //Windows 64-bit platform

        /build              //Make and build files, IDE project files
            /linux_AMD64    //Linux AMD64 platform
            /linux_i386     //Linux 32-bit platform
            /macosx         //Mac OS X
            /win32          //Windows 32-bit platform
            /win64          //Windows 64-bit platform

        /config             //Configuration files that accompany the binaries

        /data               //Data files that accompany the binaries

        /doc                //Documentation

        /lib                //External or third-party libraries
            /platforms      //Platform-specific code for ...
                      /linux_AMD64    //Linux AMD64 platform
                      /linux_i386     //Linux 32-bit platform
                      /macosx         //Mac OS X
                      /win32          //Windows 32-bit platform
                      /win64          //Windows 64-bit platform
            /src            //Available library source code in subfolders

        /src                //Source code tree - this will contain main.cpp
            /bindings       //Bindings to other languages such as ...
                      /python
                      /Java
            /h              //Header files
            /modules        //Platform-independent modules, components or subprojects
            /platforms      //Platform-specific code for ...
                      /linux_AMD64 //Linux AMD64 platform-specific code
                      /linux_i386  //Linux 32-bit platform-specific code
                      /macosx
                      /win32       //Windows 32-bit platform-specific code
                      /win64       //Windows 64-bit platform

        /test               //Automated test scripts

提案があれば、ぜひ聞いてください。この構造を作成するのに役立つツールがあるのだろうか。

CMakeとSubversionの使用を計画しています。

c++cross-platform
54
Kevin P.

構造は私にはよく見えますが、いくつかの点があります：

  • c ++ヘッダーとソースファイルを別々のディレクトリに分割するのは正常ですが、モジュールディレクトリに表示していない構造がある可能性があります。
  • おそらく、ディレクトリに* .objのような中間ファイルを入れたい
  • デバッグとリリースの出力ファイルには異なるディレクトリが必要になります
  • innoSetupのようなインストーラーとそのインストールファイルのディレクトリは便利です-これらをバージョン管理するかどうかを哲学的に決定する必要があります

構造を作成するためのツールについては、bashスクリプトの作成に数分を費やすだけで十分です。同じツール（bashなど）をすべてのプラットフォームで利用できるようにする価値があります。

11
anon

バイナリファイルに異なるプラットフォームフォルダーが必要なのはなぜですか？このソースコードを異なるプラットフォームで同じファイルシステムを使用してビルドしますか？

はいの場合、コンパイラ固有のフォルダも必要だと思います。

デバッグビルドとリリースビルドに異なるフォルダーを使用しないのはなぜですか、おそらくユニコードと非ユニコードのシングルスレッドまたはマルチスレッドのビルドですか？

BjamまたはScons make replacersを見てください。たぶん、あなたはビルドディレクトリに別のフォルダを必要としません。

「modules」ディレクトリのすべてのモジュールに、テスト用の「tests」ディレクトリが含まれている方が良いと思います。

そして最後に-ブーストライブラリをご覧ください。

また、プラットフォームに依存しない別のプロジェクトからアイデアを得るようにしてください。

Boostフォルダー構造：

boost - root dir
- boost - library header lib ( for users )
- libs - library source dir ( one dir per lib )
    - build - library build files ( if they are needed )
    - doc - documentation files
    - example - sample programs
    - src - library source files
    - test - programs and srcipts for testing module
- bin - created by bjam build system
    - libs
        - <lib-name>
            for all compiled folders from libs [example|test|build]
                - <compiler-name>/<[static|dynamic]-link>/<[debug|release]>/<[threading mode]>
                    contain builded [obj|dll|lib|pdb|so|o|etc] files see detailed information in bjam build system

- doc
- tools

Bjamを選択した場合-ビルドおよびビンのフォルダー構造は関係ありません。

また、libs/src/dirには、すべてのプラットフォームファイルの独自のファイルと、プラットフォーム固有のファイルのカップルディレクトリを含めることができます。

フォルダー構造に深刻な問題は見られません。プロジェクトのプロトタイプの作成を開始すると、おそらく問題が発生するでしょう。

8
bayda

私は最近 パッケージヘッダーに関する質問 を1つのディレクトリに投稿しましたが、少数のインクルードディレクトリを使用することにしました。

Win64に対応しますか？それはますます重要な目標になります。

しないでくださいビルド中間ファイルを、svnにチェックインされているツリーの下の任意の場所に置きます。これを行うと、svnクライアントツールに応じて、リポジトリにないファイルとして多くのノイズが生成されます。これにより、追加したファイルを表示するには、リポジトリにする必要があります。

代わりに、コンパイラが許可する場合は、中間ディレクトリを片側に置きます。

それ以外の場合は、中間ディレクトリ全体をsvn除外プロパティに追加してください。一部のGUIは、他のGUIよりも簡単にできます（Windowsのカメ、OS/Xのバージョン）。

2
Andy Dent

ビルドファイルの分類にアーキテクチャを使用しないことをお勧めしますか？

提案されたフォルダー構造を適用しようとしましたが、一般的なLinux Makefile定義とVisual Studioプロパティファイルを配置するための正しい場所が見つかりませんでした。以下についてはどうですか：

/project
   /build
      /linux
      /macosx
      /win32 (or win)

そして、ケースの例は以下を含みます：

/project
   /build
      /linux
         Make.defs
         Makefile  [i386, AMD64]
      /win32
         /VC8
            /<project>
               <project>.vcproj
            <solution>.sln  [Win32, x64]
         /VC11
            /<project>
               <project>.vcxproj
            <solution>.sln  [Win32, x64, ARM]

構成を通じてアーキテクチャビルドを定義したくない場合、プラットフォームタイプの下の別のフォルダーレイヤーはどうですか？

/project
   /build
      /linux
         /linux_AMD64
         /linux_i386
      /macosx
         /?
      /win32 (or win)
         /win32
         /win64

特定のプロジェクトにプラットフォーム用の共通ビルドファイルがない場合は、元の構造で十分です。

0
jdknight