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文件，那么原来的结构就足够了。
