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

查看:267
本文介绍了混合C ++和Python的项目的目录结构的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

假设您想创建一个可以混合使用 C ++ Python 的编程项目。 Foo C ++ 项目结构使用 CMake ,并且使用 em>。树结构看起来像这样:

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

现在您想要使用 Foo 项目

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

此结构是使用 cookiecutter的pypackage模板创建的。 BoilerplatePP模板也可以使用cookiecutter(没有 Swig 部分)生成 CMake C ++
现在我有两个项目的结构,考虑到开发将主要发生在 Python 和项目将运行在不同的系统,我需要解决以下问题:

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. 最好的混合方法是什么?我应该折叠两个根目录吗?我应该将 Foo C ++ 项目作为项目的目录,还是其他方式?我可能会倾向于将整个 C ++ 结构显示在 Python 项目的根目录下的文件夹中,但我想知道先验任何陷阱,因为 CMake 系统是相当强大的,可以方便地做其他方式。

  2. 如果我决定把中的 Foo 项目是 Python setuptools包强大的 CMake 构建系统?我问这是因为,当我看一看 Bar 项目,在顶层看起来只有一堆脚本,但我不知道这是否等同于 CMake

  3. 上述项目只有一个 / em>目录,但我假设每当这个项目扩展,而不是在根级别有许多其他目录,包含 Python 代码的其他目录将放置在 bar 。这是正确的(在 Pythonic 的意义上)吗?

  4. 我假设一个蛋将从整个项目产生,在许多不同的python系统。是 Foo 项目创建的模块的集成容易吗?我假设此模块将创建在不同于 bar 的目录中。

  5. 为了 > bar 目录中,由 Swig 创建的模块必须可用,因此我认为最直接的方法是修改环境变量 PYTHONPATH 使用 CMake 系统。这是很好还是有更好的方法?

  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?


推荐答案

没有在包含它的Python包外使用:

你可以安全地将C ++代码放在拥有它的python包中。在您的示例中的bar目录下有foo目录。

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.

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

我一定会尝试以包的方式思考,独立的部分是自包含的。所有独立的部件都在同一层。如果一个部分依赖于另一个部分,则从相同级别的相应包导入。这是依赖关系通常工作的方式。

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.

我不会包括一个在另一个,因为一个不严格属于另一个。如果你开始一个需要foo的第三个项目,但不需要bar呢?

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"?

我将foo和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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆