C++ 的目录结构图书馆

发布于 2024-08-04 10:11:25 字数 1142 浏览 3 评论 0原文

我正在开发一个 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
    ...

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

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

原文

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 Python bindings. 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.

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 Automake tools 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.

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.

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?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

梦里的微风 2024-08-11 10:11:26

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/ 目录。我也不使用自动工具，而是更喜欢使用 CMake。）

我给您的建议是您应该选择对您有意义（和您的团队）的目录布局。采取对您选择的开发环境、构建工具和源代码控制最合理的方式。

One thing that's very common among Unix libraries is that they are organized such that:

./         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 /usr where:

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

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

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.

回复收藏 0 原文

醉酒的小男人 2024-08-11 10:11:26

我最近遇到的一个很棒的约定可能会有所帮助：干草叉布局（也在

总而言之，小节 1.3 指出：

PFL 规定了应出现在项目树根部的几个目录。并非所有目录都是必需的，但它们都有指定的用途，并且文件系统中的任何其他目录都不能承担这些目录之一的角色。也就是说，如果需要使用这些目录，则必须使用这些目录。
其他目录不应出现在根目录中。
build/：一个特殊目录，不应被视为项目源代码的一部分。用于存储临时构建结果。不得签入源代码管理。如果使用源代码控制，则必须使用源代码控制忽略列表来忽略。
src/：主要可编译源位置。对于具有不使用子模块的已编译组件的项目，必须存在。
在存在 include/ 的情况下，还包含私有标头。
include/：公共标头的目录。可能存在。对于不区分私有/公共标头的项目，可以省略。对于使用子模块的项目可以省略。
tests/：测试目录。
examples/：示例和示例的目录。
external/：项目要使用的包/项目的目录，但不作为项目的一部分进行编辑。
extras/：包含项目额外/可选子模块的目录。
data/：包含项目的非源代码方面的目录。这可能包括图形和标记文件。
tools/：包含开发实用程序的目录，例如构建和重构脚本
docs/：项目文档的目录。
libs/：主项目子模块的目录。

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

回复收藏 0 原文

注定孤独终老 2024-08-11 10:11:26

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

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

回复收藏 0 原文

故事未完 2024-08-11 10:11:26

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

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

回复收藏 0 原文