86

我正在开发一个 C++ 库。最终，我想让它在多个平台（至少 Linux 和 Windows）上公开可用，以及一些示例和Python绑定。工作进展顺利，但目前该项目相当混乱，完全内置于 Visual C++ 中并用于Visual C++，根本不是多平台的。

因此，我觉得清理工作是有必要的。我想改进的第一件事是项目的目录结构。我想创建一个适合Automake工具的结构，以便在多个平台上轻松编译，但我以前从未使用过这些。由于我仍将在 Visual Studio 中进行（大部分）编码，因此我还需要在某个地方保存我的 Visual Studio 项目和解决方案文件。

我试图用谷歌搜索“C++ 库目录结构”之类的术语，但似乎没有任何有用的东西出现。我找到了一些非常基本的指导方针，但没有明确的解决方案。

在查看一些开源库时，我想到了以下内容：

\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
    ...

我以前没有/很少有多平台开发/开源项目的经验，并且很惊讶我找不到任何关于如何构建这样一个项目的好的指导方针。

通常应该如何构建这样一个图书馆项目？可以推荐阅读什么？有没有一些很好的例子？

4

5 回答 5

111

在 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`

它在某种程度上反映了传统的 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.

当然，这些可能最终会出现/usr/local（这是 GNU autoconf 的默认安装前缀），并且它们可能根本不遵守这种结构。

没有硬性规定。我个人不以这种方式组织事情。（例如，除了最大的项目之外，我完全避免使用./src/目录。我也不使用自动工具，而是更喜欢 CMake。）

我对您的建议是，您应该选择对您（和您的团队）有意义的目录布局。为您选择的开发环境、构建工具和源代码控制做任何最明智的事情。

于 2009-09-09T09:41:05.713 回答
22

我最近遇到了一个很棒的约定，它可能会有所帮助：The Pitchfork Layout（也在GitHub 上）。

总而言之，第1.3小节指出：

PFL 规定了几个应该出现在项目树根目录的目录。并非所有目录都是必需的，但它们具有指定的用途，并且文件系统中的任何其他目录都不能承担这些目录之一的角色。也就是说，如果需要这些目录，则必须使用这些目录。

其他目录不应出现在根目录中。

build/：一个特殊的目录，不应被视为项目源的一部分。用于存储临时构建结果。不得签入源代码管理。如果使用源代码管理，则必须使用源代码管理忽略列表来忽略。

src/: 主要的可编译源位置。对于具有不使用子模块的已编译组件的项目，必须存在。在存在的情况下include/，还包含私有标头。

include/：公共标头目录。可能在场。对于不区分私有/公共标头的项目，可以省略。对于使用子模块的项目，可以省略。

tests/: 测试目录。

examples/：样本和示例目录。

external/：项目使用的包/项目的目录，但不作为项目的一部分进行编辑。

extras/：包含项目的额外/可选子模块的目录。

data/：包含项目非源代码方面的目录。这可能包括图形和标记文件。

tools/：包含开发实用程序的目录，例如构建和重构脚本

docs/: 项目文档目录。

libs/：主要项目子模块的目录。

此外，我认为该extras/目录是您的 Python 绑定应该去的地方。

于 2019-02-24T14:39:29.587 回答
4

我认为实际上没有任何好的指导方针。大部分只是个人喜好。不过，某些 IDE 将为您确定基本结构。例如，Visual Studio 将创建一个单独的 bin 文件夹，该文件夹分为 Debug 和 Release 子文件夹。在 VS 中，当您使用不同的目标编译代码时，这很有意义。（调试模式，发布模式。）

正如 grayfade 所说，使用对您有意义的布局。如果其他人不喜欢它，他们将不得不自己重组它。幸运的是，大多数用户会对您选择的结构感到满意。（除非它真的很乱。）

于 2009-09-09T10:07:05.777 回答
4

我发现 wxWidgets 库（开源）就是一个很好的例子。它们支持许多不同的平台（Win32、Mac OS X、Linux、FreeBSD、Solaris、WinCE...）和编译器（MSVC、GCC、CodeWarrior、Watcom 等）。您可以在此处查看树布局：

https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/

于 2009-09-09T10:27:25.267 回答
-1

我真的可以推荐你使用 CMake ......它用于跨平台开发，它比 automake 灵活得多，使用 CMake，你将能够在所有系统上使用自己的目录结构编写跨平台代码。

于 2019-02-16T23:48:59.283 回答