Повышение проблем переносимости Python
У меня есть DLL, написанная на C ++, которую я хочу экспортировать в Python для запуска регрессии и модульного тестирования (проще поддерживать и запускать регрессию с Python).
Для этого я хочу использовать Boost.Python для экспорта основного API библиотеки DLL, чтобы он мог использоваться в Python.
Мои сборки выглядят следующим образом:
- MyLibrary.dll // основная библиотека API C ++
- MyLibrary.pyd // тонкий проект dll, содержащий только
BOOST_PYTHON_MODULEэкспорт определений (зависит от MyLibrary.dll) - … // другие файлы C ++ dll, от которых зависит MyLibrary.dll
У меня были некоторые проблемы с получением ссылки MyLibrary.pyd, но после того, как я немного перебрал вопросы (например, Вот) Я понял, что мне нужно пересобрать буст, указывая b2.exe к моей конкретной версии Python. После чего я смог импортировать и запустить мою библиотеку из Python (на моя машина одна).
Технические данные: я собираю библиотеки с boost 1.51, Python 3.23 для Windows 7 x64 и MSVC-10.0 (мои собственные проекты созданы на основе VS2010). Вариант, который я использую для связи с boost, — это разделяемые библиотеки, 64-адресная модель, выпускаемая соответственно с моими собственными сборками.
Проблема в том, что когда я пытаюсь импортировать библиотеку (созданную на моей машине) на другую машину, python жалуется:
ImportError: DLL load failed: The specified procedure could not be found.
На линии import MyLibrary
Что вызывает следующие вопросы:
- Является ли MyLibrary.pyd, который я создал на своей машине, «переносимым на python»? Это значит, будет ли он работать на других версиях Python, кроме 3.23 (версии, с которой я собирался создать boost.python на моей машине)?
- Должен ли пользователь MyLibrary.pyd пересобрать надстройку с его собственной версией python, чтобы успешно ее импортировать?
- До сих пор мы использовали предварительно созданную программу установки буста для окон, поставляемых BoostPro. С какой версией Python связана эта сборка, и могу ли я избавить своих пользователей от головной боли при создании надстройки самостоятельно, если мы просто решим работать с «правильной» версией Python во всей команде (с версией BoostPro, связанной с)?
Решение
Взгляните на PEP 384 на http://docs.python.org/3.2/whatsnew/3.2.html.
http://www.boost.org/doc/libs/1_52_0/libs/python/doc/news.html показывает, что в последнее время не было никакого реального прогресса, поэтому я сомневаюсь, что Boost.Python поддерживает или, по крайней мере, был протестирован с определенным Py_LIMITED_API.
Согласно моему опыту с Python 2.x совместимостью с использованием обоих Boost.Python и PyCXX (я еще не работал со строкой 3.x):
- Нет, не будет. ABI переносит только изменения микро версии.
- Не совсем. Пользователь предоставленного вами бинарного файла MyLibrary.pyd не сможет загрузить его с использованием другой основной / минорной версии Python. Конфигурация сборки Boost у нее не имеет значения. Вам необходимо иметь сборки Boost.Python с каждой минорной версией Python, которую вы хотите поддерживать. Это включает в себя отдельные сборки для 32 и 64-битных установок Python.
Мой совет — попытаться собрать Boost из исходного кода с определенным Py_LIMITED_API. Я не гарантирую, что это удастся, но это стоит попробовать.
Если это не помогло, попросите своих товарищей по команде использовать ту же версию Python, что и у вас, и, конечно же, 64-битную Windows (так как .pyd сам по себе является 64-битным). Или даже лучше настроить компьютер CI, который будет собирать ваш модуль python в каждой требуемой конфигурации, чтобы ваши клиенты могли выбрать правильный двоичный файл. Пусть ваши товарищи по команде создают и используют свои собственные версии MyLibrary.pyd только для локального использования.
Другие решения
Других решений пока нет …