C++ 库的目录结构
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1398445/
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
Directory structure for a C++ library
提问by TC.
I am working on a C++ library. Ultimately, I would like to make it publicly available for multiple platforms (Linux and Windows at least), along with some examples and Pythonbindings. Work is progressing nicely, but at the moment the project is quite messy, built solely in and for Visual C++and not multi-platform at all.
我正在研究 C++ 库。最终，我想让它在多个平台（至少是 Linux 和 Windows）上公开可用，以及一些示例和Python绑定。工作进展顺利，但目前该项目相当混乱，仅针对Visual C++构建，根本没有跨平台。
Therefore, I feel a cleanup is in order. The first thing I'd like to improve is the project's directory structure. I'd like to create a structure that is suitable for the Automaketools to allow easy compilation on multiple platforms, but I've never used these before. Since I'll still be doing (most of the) coding in Visual Studio, I'll need somewhere to keep my Visual Studio project and solution files as well.
因此，我觉得清理是有序的。我要改进的第一件事是项目的目录结构。我想创建一个适合Automake工具的结构，以便在多个平台上轻松编译，但我以前从未使用过这些。由于我仍将在 Visual Studio 中进行（大部分）编码，因此我还需要在某个地方保存我的 Visual Studio 项目和解决方案文件。
I tried to google for terms like "C++ library directory structure", but nothing useful seems to come up. I found some very basic guidelines, but no crystal clear solutions.
我试图用谷歌搜索诸如“C++ 库目录结构”之类的术语，但似乎没有任何有用的信息出现。我找到了一些非常基本的指导方针，但没有明确的解决方案。
While looking at some open source libraries, I came up with the following:
在查看一些开源库时，我想出了以下几点：
\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
...
I have no/little previous experience with multi-platform development/open source projects and am quite amazed that I cannot find any good guidelines on how to structure such a project.
我以前没有/几乎没有多平台开发/开源项目的经验，并且很惊讶我找不到关于如何构建这样一个项目的任何好的指导方针。
How should one generally structure such a library project? What ca be recommended to read? Are there some good examples?
通常应该如何构建这样一个库项目？推荐阅读什么？有什么好的例子吗？
回答by greyfade
One thing that's very common among Unix libraries is that they are organized such that:
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`
It somewhat reflects the traditional Unix filesystem under /usrwhere:
它在某种程度上反映了传统的 Unix 文件系统，/usr其中：
/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.
Of course, these may end up in /usr/local(which is the default install prefix for GNU autoconf), and they may not adhere to this structure at all.
当然，这些最终可能会出现在/usr/local（这是 GNU autoconf 的默认安装前缀）中，并且它们可能根本不遵守这种结构。
There's no hard-and-fast rule. I personally don't organize things this way. (I avoid using a ./src/directory at all except for the largest projects, for example. I also don't use autotools, preferring instead CMake.)
没有硬性规定。我个人不会这样组织事情。（./src/例如，除了最大的项目，我完全避免使用目录。我也不使用 autotools，而是更喜欢 CMake。）
My suggestion to you is that you should choose a directory layout that makes sense for you(and your team). Do whatever is most sensible for your chosen development environment, build tools, and source control.
我对您的建议是，您应该选择对您（和您的团队）有意义的目录布局。为您选择的开发环境、构建工具和源代码控制做任何最明智的事情。
回答by Gabriel Galli
There is this awesome convention that I recently came across that might be helpful: The Pitchfork Layout(also on GitHub).
我最近遇到了一个可能有用的很棒的约定：The Pitchfork Layout（也在GitHub 上）。
To sum up, subsection 1.3states that:
总而言之，第1.3小节指出：
PFL prescribes several directories that should appear at the root of the project tree. Not all of the directories are required, but they have an assigned purpose, and no other directory in the filesystem may assume the role of one of these directories. That is, these directories must be the ones used if their purpose is required.
Other directories should not appear at the root.
build/: A special directory that should not be considered part of the source of the project. Used for storing ephemeral build results. must not be checked into source control. If using source control, must be ignored using source control ignore-lists.
src/: Main compilable source location. Must be present for projects with compiled components that do not use submodules. In the presence ofinclude/, also contains private headers.
include/: Directory for public headers. May be present. May be omitted for projects that do not distinguish between private/public headers. May be omitted for projects that use submodules.
tests/: Directory for tests.
examples/: Directory for samples and examples.
external/: Directory for packages/projects to be used by the project, but not edited as part of the project.
extras/: Directory containing extra/optional submodules for the project.
data/: Directory containing non-source code aspects of the project. This might include graphics and markup files.
tools/: Directory containing development utilities, such as build and refactoring scripts
docs/: Directory for project documentation.
libs/: Directory for main project submodules.
PFL 规定了几个应该出现在项目树根部的目录。并非所有目录都是必需的，但它们有指定的用途，文件系统中的任何其他目录都不能承担这些目录之一的角色。也就是说，如果需要使用这些目录，则必须使用这些目录。
其他目录不应出现在根目录中。
build/: 不应被视为项目源的一部分的特殊目录。用于存储临时构建结果。不得签入源代码管理。如果使用源代码控制，必须使用源代码控制忽略列表来忽略。
src/: 主要可编译源位置。对于包含不使用子模块的已编译组件的项目，必须存在。在存在的情况下include/，还包含私有标头。
include/：公共标题的目录。可能存在。对于不区分私有/公共标头的项目，可以省略。对于使用子模块的项目，可以省略。
tests/: 测试目录。
examples/：示例和示例目录。
external/：项目使用的包/项目的目录，但不作为项目的一部分进行编辑。
extras/：包含项目的额外/可选子模块的目录。
data/：包含项目非源代码方面的目录。这可能包括图形和标记文件。
tools/：包含开发实用程序的目录，例如构建和重构脚本
docs/: 项目文档目录。
libs/: 主要项目子模块的目录。
Additionally, I think the extras/directory is where your Python bindings should go.
此外，我认为该extras/目录是您的 Python 绑定应该去的地方。
回答by Wim ten Brink
I don't think there's actually any good guidelines for this. Most of it is just personal preference. Certain IDE's will determine a basic structure for you, though. Visual Studio, for example, will create a separate bin folder which is divided in a Debug and Release subfolders. In VS, this makes sense when you're compiling your code using different targets. (Debug mode, Release mode.)
我认为实际上没有任何好的指导方针。大多数只是个人喜好。不过，某些 IDE 将为您确定基本结构。例如，Visual Studio 将创建一个单独的 bin 文件夹，该文件夹分为 Debug 和 Release 子文件夹。在 VS 中，当您使用不同的目标编译代码时，这是有意义的。（调试模式，发布模式。）
As greyfade says, use a layout that makes sense to you. If someone else doesn't like it, they will just have to restructure it themselves. Fortunately, most users will be happy with the structure you've chosen. (Unless it's real messy.)
正如greyfade 所说，使用对您有意义的布局。如果其他人不喜欢它，他们将不得不自己重新构建它。幸运的是，大多数用户会对您选择的结构感到满意。（除非真的很乱。）
回答by Milan Babu?kov
I find wxWidgets library (open source) to be a good example. They support many different platforms (Win32, Mac OS X, Linux, FreeBSD, Solaris, WinCE...) and compilers (MSVC, GCC, CodeWarrior, Watcom, etc.). You can see the tree layout here:
我发现 wxWidgets 库（开源）就是一个很好的例子。它们支持许多不同的平台（Win32、Mac OS X、Linux、FreeBSD、Solaris、WinCE...）和编译器（MSVC、GCC、CodeWarrior、Watcom 等）。您可以在此处查看树布局：
回答by stuv_2028
I can realy recommend you using CMake... it's for cross platform development and it's much more flexible that automake, use CMake and you will be able to write cross platform code with your own direcory structure on all systems.
我真的可以推荐你使用 CMake ......它用于跨平台开发，它比 automake 更灵活，使用 CMake 你将能够在所有系统上使用自己的目录结构编写跨平台代码。
