C ++跨平台库和绑定的最佳文件夹结构

我即将开始使用C ++编写一个跨平台的库。 顺便说一下,我打算实现其他语言(如Python,Java等)的绑定。库需要在主要平台上可用:win32,Linux和Mac OSX。

尽pipe应用程序实际上是一个库,但是一些基本的控制台程序将与其捆绑在一起进行演示和testing。

在我开始在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 

如果您有任何build议,我很乐意听到他们的意见。 我想知道是否有一个工具可以帮助创build这个结构。

我正在计划使用CMake和Subversion。

结构看起来不错,但有几点:

  • 将C ++头文件和源文件分离到不同的目录是正常的,或者在你没有显示的模块目录中有结构?
  • 你可能希望目录把* .obj这样的中间文件放进去
  • 您将需要不同的目录来debugging和发布输出文件
  • 像InnoSetup这样的安装目录及其安装文件可能是有用的 – 你必须做出关于是否对版本进行控制的哲学决定

至于创build结构的工具,花费几分钟时间写一个bash脚本就是所有你需要的 – 值得在所有平台上使用相同的工具(比如bash)。

为什么你需要不同的二进制文件平台文件夹? 你打算在不同的平台下构build这个源代码,但使用相同的文件系统?

如果是的话,我认为你也需要特定的文件夹。

为什么你不使用不同的文件夹进行debugging和发布构build,也许unicode和非unicode,单线程或multithreading构build?

看bjam或Scons替代者。 也许你不需要build立目录中的不同文件夹。

我认为如果“模块”目录中的所有模块都包含“testing”目录,那么testing自己会更好。


最后 – 看到boost库,这个平台结构很好的独立库。

也尝试从antother平台独立项目中获得创意。

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 

如果你selectbjam – 你不会关心构build和bin文件夹结构。

另外你的libs / src / dir可以包含所有平台文件的自己的文件,还可以包含特定于平台文件的目录。

我没有看到在你的文件夹structre中的任何严重问题,也许你会看到他们,当开始写项目原型。

我最近在一个目录中发布了一个关于打包头的问题 ,决定使用less量的include目录。

你要去迎合Win64吗? 这将是一个越来越重要的目标。

不要把你的构build中间文件放到被svn检查的树下。 如果你这样做,根据你的svn客户端工具,它们会产生大量的噪音,作为不在库中的文件。 这使得很难看到你已经添加的文件应该在仓库中。

相反,如果你的编译器允许的话,把中间目录放到一边。

否则,请确保将整个中间目录添加到svn排除属性中。 一些graphics用户界面比其他用户更容易(Windows上的Tortoise,OS / X上的Cornerstone或Versions)。

可能我build议不要使用该体系结构对构build文件进行分类?

我试图应用你提出的文件夹结构,但我找不到把普通的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] 

如果您不想通过configuration来定义架构版本,那么在平台types下的另一个文件夹层呢?

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

如果一个给定的项目没有平台的通用构build文件,那么原来的结构就足够了。