C ++库的目录结构

问题描述 投票:69回答:5

我正在开发一个C ++库。最后,我想公开提供多个平台(至少Linux和Windows),以及一些示例和Python绑定。工作进展顺利,但目前该项目非常混乱,仅为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
    ...

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

人们应该如何构建这样的图书馆项目?建议阅读什么?有一些很好的例子吗?

c++ directory-structure automake
5个回答
94
投票

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

它有点反映了/usr下的传统Unix文件系统,其中:

/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/目录。我也不使用autotools,而是选择CMake。)

我的建议是你应该选择一个对你(和你的团队)有意义的目录布局。为您选择的开发环境,构建工具和源代码控制做最合理的事情。


5
投票

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

正如greyfade所说,使用对你有意义的布局。如果其他人不喜欢它,他们只需要自己进行重组。幸运的是,大多数用户会对您选择的结构感到满意。 (除非它真的很乱。)


5
投票

我发现wxWidgets库(开源)是一个很好的例子。它们支持许多不同的平台(Win32,Mac OS X,Linux,FreeBSD,Solaris,WinCE ......)和编译器(MSVC,GCC,CodeWarrior,Watcom等)。你可以在这里看到树的布局:

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


4
投票

我最近遇到的这个令人敬畏的惯例可能会有所帮助:The Pitchfork Layout(也在GitHub上)。

总而言之,1.3小组指出:

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

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

build/:一个特殊目录,不应被视为项目源的一部分。用于存储短暂的构建结果。不得检查源代码管理。如果使用源代码管理,则必须使用源代码控制ignore-lists忽略。

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

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

tests/:测试目录。

examples/:样本和示例目录。

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

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

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

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

docs/:项目文档目录。

libs/:主项目子模块的目录。

另外,我认为extras/目录是你的Python绑定should go的地方。


0
投票

我真的可以推荐你使用CMake ...它用于跨平台开发,而且它更灵活,使用CMake,你将能够在所有系统上用你自己的直接结构编写跨平台代码。

© www.soinside.com 2019 - 2024. All rights reserved.