C + + 库的目录结构

我正在开发一个 C + + 库。最后，我希望将它公开地提供给多个平台(至少是 Linux 和 Windows) ，以及一些示例和 巨蟒绑定。工作进展顺利，但目前该项目是相当混乱的，建立在单独的和为 Visual C + + ，而不是多平台在所有。

所以，我觉得应该清理一下。我想改进的第一件事是项目的目录结构。我想创建一个适合于 汽车制造工具的结构，以便在多个平台上轻松编译，但我以前从未使用过这些工具。由于我仍将在 VisualStudio 中进行(大部分)编码，因此我还需要一个地方来保存 VisualStudio 项目和解决方案文件。

我试图在谷歌上搜索“ 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
...

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

一个人一般应该如何构建这样一个图书馆项目? 可以推荐阅读什么? 是否有一些好的例子？

53542 次浏览
小开
最佳答案

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.

小开

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

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

小开

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:

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

小开

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.

小开

There is this awesome convention that I recently came across that might be helpful: The Pitchfork Layout (also on GitHub).

To sum up, subsection 1.3 states that:

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 of include/, 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.

Additionally, I think the extras/ directory is where your Python bindings should go.


提交答案