用于混合C ++和Python的项目的目录结构 [英] directory structure for a project that mixes C++ and Python

问题描述

假设您想要创建一个将 C ++ 和 Python 混合在一起的编程项目。 Foo C ++ 项目结构使用 CMake ，而模块是通过使用 EM>。树结构看起来像这样：

 ├──CMakeLists.txt 
├──FooConfig.cmake。在
├──FooConfigVersion.cmake.in 
├──Makefile 
├──README 
├──foo 
│├──CMakeLists.txt 
│├──config.hpp.in 
│├──foo.cpp 
│└──foo.hpp 
└──swig 
└──foo。 i 
  

现在您想使用一个 Foo 项目

├──CONTRIBUTING.rst
├──HISTORY.rst
├──LICENSE
├──MANIFEST.in
├─Makefile
├──README.rst
├──文档
│├──Makefile
│├──authors.rst
│├──conf.py
│ ├──contribution.rst
│├──history.rst
│ ├──index.rst
│├──installation.rst
│├──make.bat
│├──readme.rst
│└──usage.rst
├──bar
│├──__init__.py
│└──bar.py
├──requirements.txt
├──setup.cfg
├──setup.py
├──测试
│├──__init__.py
│└──test_bar.py
└──tox.ini

这个结构是使用 cookiecutter的包装模板。还可以使用BoilerplatePP模板来生成使用cookiecutter（no Swig 部分）的CMake C ++ 项目。
所以现在我有两个项目的结构，并且考虑到这个开发将主要发生在Python 中，项目将在不同的系统中运行，我需要解决以下问题问题：

1. 混合它们最好的方法是什么？我应该折叠根目录吗？我应该将 Foo C ++ 项目作为栏项目的目录或其他方式？我可能倾向于将上面显示的整个 C ++ 结构放在Python 项目的根级别的文件夹中，但我想先知 / em>任何陷阱，因为CMake 系统是相当强大的，可能方便其他方式。


2. 如果我决定把 Foo 项目作为栏中的目录，是与 CMake 构建系统一样强大的Python setuptools包？我问这个是因为当我看看 Bar 项目时，顶层似乎只有一堆脚本，但是我不知道这是否相当于CMake
/ em>目录，但是我假设每当这个项目扩展，而不是在根级别上有很多其他的目录，那么包含 Python 代码的其他目录将放在栏中。这是正确的（在Pythonic的意义上）？

3. 我假设从整个项目中将生产一个鸡蛋，以便可以安装和运行在许多不同的python系统。由 Foo 项目创建的模块的集成是否容易？我假设这个模块将被创建在不同于栏的目录中。


4. 为了 > bar 目录，由 Swig 创建的模块必须可用，所以我想最直接的方法是修改环境变量 PYTHONPATH 使用 CMake 系统。这是罚款还是有更好的方法？






解决方案

如果C ++应用程序在包含它的Python包之外没有用处：

你可以安全地将C ++代码放在拥有它的python包中。在您的示例中的bar目录中的foo目录中。这将使最终的Python模块打包更容易。

如果C ++应用程序可重用：

我一定会尝试用包来思考，独立部分是独立的。所有独立部件都在同一水平上。如果一个部分取决于另一个部分，则从相同级别的相应包导入。这是依赖关系通常工作的方式。

我不会在另一个中包含一个，因为一个不是严格属于另一个。如果您启动了需要foo但不需要bar的第三个项目呢？

我将foo和bar包放入相同的项目目录（我可能会给每个包，它是自己的代码存储库，所以每个包可以轻松维护和安装）。

Say you want want to create a programming project that mixes C++ and Python. The Foo C++ project structure uses CMake, and a Python module is created by using Swig. The tree structure would look something like this:

├── CMakeLists.txt
├── FooConfig.cmake.in
├── FooConfigVersion.cmake.in
├── Makefile
├── README
├── foo
│   ├── CMakeLists.txt
│   ├── config.hpp.in
│   ├── foo.cpp
│   └── foo.hpp
└── swig
    └── foo.i

Now you would like to make use of the Foo project within a Python project, say Bar:

├── AUTHORS.rst
├── CONTRIBUTING.rst
├── HISTORY.rst
├── LICENSE
├── MANIFEST.in
├── Makefile
├── README.rst
├── docs
│   ├── Makefile
│   ├── authors.rst
│   ├── conf.py
│   ├── contributing.rst
│   ├── history.rst
│   ├── index.rst
│   ├── installation.rst
│   ├── make.bat
│   ├── readme.rst
│   └── usage.rst
├── bar
│   ├── __init__.py
│   └── bar.py
├── requirements.txt
├── setup.cfg
├── setup.py
├── tests
│   ├── __init__.py
│   └── test_bar.py
└── tox.ini

This structure was crated by using cookiecutter's pypackage template. A BoilerplatePP template is also available to generate a CMake C++ project using cookiecutter (no Swig part). So now that I have the structure of both projects, and considering that the development will take place mainly in Python and the the project will be run in different systems, I need to address the following questions:

1. What's the best way to mix them? Should I collapse both root directories? Should I have the Foo C++ project as a directory of the Bar project or the other way around? I may be inclined to put the entire C++ structure shown above in a folder at the root level of the Python project, but I would like to know a priori any pitfalls as the CMake system is quite powerful and it may be convenient to do it the other way around.
2. In case I decide to put the Foo project as a directory within Bar, is the Python setuptools package as powerful as the CMake build system? I ask this because when I take a look at the Bar project, at the top level it seems there's only a bunch of scripts, but I don't know if this is the equivalent to CMake as I'm new to Python.
3. The Bar project outlined above has a single bar directory, but I assume that whenever this project expands, instead of having many other directories at the root level, other directories containing Python code will be placed within bar. Is this correct (in the Pythonic sense)?
4. I assume that a single egg will be produced from the entire project, so that it can be installed and run in many different python systems. Is the integration of the module created by the Foo project easy? I assume that this module will be created in a different directory than bar.
5. In order for the Python code within the bar directory, the module created by Swig has to be available, so I guess the most straightforward way to do this is to modify the environmental variable PYTHONPATH using the CMake system. Is this fine or is there a better way?

解决方案

If the C++ application has no use outside the Python package that will contain it:

You can pretty safely place the C++ code within the python package that owns it. Have the "foo" directory within the "bar" directory within your example. This will make packaging the final Python module a bit easier.

If the C++ application is reusable:

I would definitely try to think of things in terms of "packages", where independent parts are self-contained. All independent parts live on the same level. If one part depends on another, you import from its corresponding "package" from the same level. This is how dependencies typically work.

I would NOT include one within the other, because one does not strictly belong to the other. What if you started a third project that needed "foo", but did not need "bar"?

I would place both "foo" and "bar" packages into the same "project" directory (and I would probably give each package it's own code repository so each package can be easily maintained and installed).

这篇关于用于混合C ++和Python的项目的目录结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！