C++ 跨平台库和绑定的最佳文件夹结构
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/718126/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Best folder structure for C++ cross-platform library and bindings
提问by Kevin P.
I am about to begin work on a cross-platform library to be written in C++. Down the road, I intend to implement bindings for other languages such as Python, Java, etc. The library needs to be available on the major platforms: win32, Linux and Mac OSX.
我即将开始使用 C++ 编写的跨平台库。未来，我打算为其他语言（如 Python、Java 等）实现绑定。该库需要在主要平台上可用：win32、Linux 和 Mac OSX。
Although the application is really a library, some basic console programs will be bundled along with it for demonstration and testing.
尽管该应用程序实际上是一个库，但会捆绑一些基本的控制台程序以进行演示和测试。
I'd like to come up with an optimum folder structure before I start storing stuff in Subversion.
在我开始在 Subversion 中存储东西之前，我想提出一个最佳的文件夹结构。
I am thinking of something like:
我在想类似的事情：
/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
If you have suggestions, I'd love to hear them. I wonder if there is a tool that can help create this structure.
如果您有任何建议，我很乐意听取他们的意见。我想知道是否有一种工具可以帮助创建这种结构。
I am planning on using CMake and Subversion.
我打算使用 CMake 和 Subversion。
回答by Kevin P.
The structure looks good to me, but there are a few points:
结构在我看来不错，但有几点：
- it's normal to separate C++ header and source files into different directories, or maybe there is structure in the modules directory you are not showing?
- you probably want directories to put intermediate files like *.obj in
- you will need different directories for debug and release output files
- a directory for installers like InnoSetup and their install files can be useful - you have to make the philosphical decision about whether to version control these
- 将 C++ 头文件和源文件分开到不同的目录中是正常的，或者模块目录中可能有你没有显示的结构？
- 您可能希望目录将诸如 *.obj 之类的中间文件放入
- 您将需要不同的目录用于调试和发布输出文件
- InnoSetup 等安装程序及其安装文件的目录可能很有用 - 您必须做出是否对这些进行版本控制的哲学决定
As for tools to create the structure, a few minutes spent writing a bash script is all you need - it's worth having the same tools (like bash) available on all platforms.
至于创建结构的工具，您只需要花几分钟编写 bash 脚本即可 - 值得在所有平台上使用相同的工具（如 bash）。
回答by bayda
Why you need different platform folders for binary files? You going to build this source code under different platoforms but with same file system?
为什么二进制文件需要不同的平台文件夹？您打算在不同的平台下使用相同的文件系统构建此源代码吗？
If yes, I think you need compiller specific folders too.
如果是，我认为您也需要编译器特定的文件夹。
Why you don't use different folders for debug and release build, maybe unicode and non-unicode, single-threading or multithreading builds?
为什么不使用不同的文件夹进行调试和发布构建，可能是 unicode 和非 unicode、单线程或多线程构建？
Look on bjam or Scons make replacers. Maybe you don't need different folders in build directory.
看看 bjam 或 Scons 的替代品。也许您不需要构建目录中的不同文件夹。
I think it will be better if all modules from "modules" directory will contain "tests" directory for test self.
我认为如果来自“modules”目录的所有模块都包含用于测试自身的“tests”目录会更好。
And last - see boost library, this platofrm independed library which have nice structure.
最后 - 参见 boost 库，这个具有良好结构的平台独立库。
Also try to get ideas from antother platform independed projects.
还尝试从另一个独立于平台的项目中获取想法。
Boost folders structure:
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
If you choose bjam - you will not be concerned on build and bin folders structure.
如果您选择 bjam - 您将不必担心 build 和 bin 文件夹结构。
Also your libs/src/ dir could contain own for all platform files and couple dirs for platform spcific files.
此外，您的 libs/src/ 目录可以包含所有平台文件的自己的目录和平台特定文件的几个目录。
I don't see any serious problems in your folders structre, maybe you will see them when start write project prototype.
我在你的文件夹结构中没有看到任何严重的问题，也许你会在开始编写项目原型时看到它们。
回答by Andy Dent
I recently posted a question about packaging headersin just one directory, decided to go with a small number of include directories.
我最近发布了一个关于在一个目录中打包头文件的问题，决定使用少量包含目录。
Are you going to cater for Win64? That will be an increasingly important target.
你要迎合Win64吗？这将是一个越来越重要的目标。
Do notput your build intermediate files anywhere under a tree being checked into svn. If you do so, depending on your svn client tools, they will generate a lot of noise as files which are not in the repository.That makes it hard to see files you've added that shouldbe in the repository.
千万不能把你的构建中间文件一棵大树下的任何地方被检查到SVN。如果您这样做，根据您的 svn 客户端工具，它们会产生大量噪音，因为这些文件不在存储库中。这使得很难看到您添加的应该在存储库中的文件。
Instead, if your compiler allows it, put the intermediate directories off to one side.
相反，如果您的编译器允许，请将中间目录放在一边。
Otherwise, make sure you add the entire intermediate directories to your svn exclusion properties. Some GUI's make that easier than others (Tortoise on Windows, Cornerstone or Versions on OS/X).
否则，请确保将整个中间目录添加到 svn 排除属性中。有些 GUI 比其他 GUI 更容易（Windows 上的 Tortoise、Cornerstone 或 OS/X 上的版本）。
回答by jdknight
Might I suggest not using the architecture to categorize build files?
我可以建议不要使用架构来对构建文件进行分类吗？
I was trying to apply your proposed folder structure but I couldn't find the correct place to put common Linux Makefile definitions and Visual Studio property files. How about just the following:
我试图应用您建议的文件夹结构，但找不到放置常见 Linux Makefile 定义和 Visual Studio 属性文件的正确位置。如何只是以下：
/project
/build
/linux
/macosx
/win32 (or win)
And example case would include:
示例案例包括：
/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]
If you don't want to define architecture builds through configurations, how about another folder layer under the platform types?
如果您不想通过配置定义架构构建，那么平台类型下的另一个文件夹层如何？
/project
/build
/linux
/linux_amd64
/linux_i386
/macosx
/?
/win32 (or win)
/win32
/win64
If a given project will not have any common build files for a platform, the original structure would suffice.
如果给定的项目没有平台的任何通用构建文件，那么原始结构就足够了。
