структура проекта для переноса множества классов C++ в cython в один общий объект

Я нашел частичные ответы в документах, списках рассылки и на этот вопрос здесь , но я хотел получить более прямой ответ, касающийся моей специфики...

Я изучаю cython, пытаясь постепенно обернуть небольшие части библиотеки, которую я уже использую, которая в настоящее время завернута в boost ::python. Я внес небольшой вклад в эту оболочку boost и использую ее в качестве справочника по C++, в то же время я использую привязки ZeroMQ Python в качестве справочника по cython.

Мой вопрос касается структуры проекта. Текущая ускоренная версия этой библиотеки компилируется в один .so, и это моя цель. Я быстро понял, что вы не можете напрямую скомпилировать несколько .pyxмодулей в один .so. Затем я начал идти по пути определения cppclassв файлах pxdи соответствующих классов реализации, экспортированных python в .pxi, и пытался включить их в один pyxдля компиляции. Сначала это работало, но когда я написал немного больше, я столкнулся с проблемами с конфликтующими несколькими определениями из-за pxiв разных местах.

Я хотел бы услышать правильный организационный подход, который решает следующие вопросы и цели:

  • Назвать публичные классы так же, какcppclass(Я делаю это сейчас, используя cppclass с другим именем pydи используя импортированное пространство имен для обработки похожих имен, аля Использование cimport для разрешения конфликтов имен)
  • Сингл .soкак скомпилированный вывод(приемлемый подход?)
  • Использую ли я подход pyxmulti -include в main pyxтолько для этого,или этот main pyxдолжен содержать что-то еще, помимо включения include?
  • Где централизованно определить константы, которые будут экспортироваться в python?
  • Существует ли предпочтительная структура папок? Прямо сейчас у меня есть все в большом каталоге srcпод моим setup.py. Смущает такое количество pxi, pxd, pyxфайлов.
  • pxiсейчас совсем не нужны? Если нет, нужно ли мне использовать защиту ifndef в стиле cython -для обработки множественных включений между разными модулями?
  • Я знаю, что привязки Python ZeroMQ создают несколько модулей и используют пакетный подход, включая их через __init__.py. Это действительно правильный подход к cython?

Для справки, проект, который я практикую для повторного -переноса, называется PyOpenNI (. опенни ). Шаблон, который использует этот проект повышения, состоит в том, чтобы собрать общие объекты в одном месте, а затем определить определение заголовка от 1 -до -1 с источником, а затем есть огромная оболочка, которая собирает все определения в единое место. А также добавлена ​​настраиваемая обработка исключений и утилиты.

22
задан Community 23 May 2017 в 12:08
поделиться