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

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

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

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

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

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

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

Ответы

ext_modules = [
    Extension(
        "openni", 
        ["src/openni.pyx"], 
        language="c++",
        include_dirs=['src/', '/usr/include/ni'],
        libraries=['OpenNI'],
    )
],

include "constants.pyx"
include "exceptions.pyx"
include "context.pyx"
...

cdef extern from "XnCppWrapper.h" namespace "xn":
    cdef cppclass Context:
           ...

from libopenni cimport *
from xncontext cimport Context as c_Context 

cdef class Context:
    cdef c_Context *handle   
        ...