LINUX.ORG.RU

Какую систему сборки выбрать для c++-библиотеки для пайтона.

 , ,


1

3

В продолжение этой темы.

Вообщем, потихонечку финализирую и готовлю к публикации свой pet-project. Но возник вопрос какую выбрать приличную сборочную систему, т.к. сейчас я использую абсолютно непортабельный Makefile с кучей костылей — и выносить такое на публику не хочу.

Собственно subj. Проект — библиотека для python, написанная на c++ с использованием pybind11.

Фактически, библиотека состоит из двух частей, которые шарят между собой некоторые хедеры:

  • frontend взаимодействующий с python-кодом, содержащий биндинги для всех классов и функций;
  • backend (которых, в перспективе будет несколько, но пока один) — динамически загружаемая библиотека, содержащая сами расчётные функции.

Подводные камни, с которыми не понимаю как правильно быть:

  • зависимости (которые я сейчас просто скриптм сгружаю с гибхаба и кладу в отдельную директорию и симлинкаю в директории с исходниками):
  • на этапе сборки backend скриптом из python делается немного кодогенерации что бы проинстанцировать все комбинации шаблонных параметров.
  • разнцые опции компилятора при сборке front- и backend, в дальнейшем и разные компиляторы (т.к. буду использовать hip и cuda)
  • как-то хочется что бы оно минимально зависело от версии интерпретатора и избегать подобного:
    ImportError: Python version mismatch: module was compiled for Python 3.10, but the interpreter version is incompatible: 3.11.4 (main, Jul  5 2023, 14:15:25) [GCC 11.2.0].
    (upd: избежать не получится)

Соответственно, хочется что бы всё это это собиралось как-то максимально безболезненно, желательно прямо в python-пакет, который можно будет впоследствии установить pip-ом. Вероятно, мне нужна какая-то python-центричная сборочная система.

Так-как сам я не программист, то спрашиваю советов и best-practice для моего случая.

★★★★★

Последнее исправление: thunar (всего исправлений: 3)

(upd: избежать не получится)

Получится, если сделать сишное api и вызывать динамически через ffi/ctypes. Если ты делаешь именно красивый объектный интерфейс к сишной библиотеке, такое предпочтительнее чем городить весь этот огород с c++ биндингами.
Но такое может оказаться сильно медленнее чем нативный питоновский модуль.
Сборку нативной части можно организовать через waf, он на python и можно прям в скрипте сборки будет сделать кодогенерацию
https://waf.io/book/

mittorn ★★★★★
()

у всех библиотек из списка (кроме тех, которые header-only и которым вообще не нужны никакие сборочные системы) в доках представлены примеры подключения с помощью cmake. Местные чудики тебе конечно насоветуют всякой чуши, но - cmake де-факто стандарт для плюсов, им и надо пользоваться.

Lrrr ★★★★★
()

зависимости (которые я сейчас просто скриптм сгружаю с гибхаба и кладу в отдельную директорию и симлинкаю в директории с исходниками)

CMake + CPM.cmake.

dataman ★★★★★
()

Обычно ты пихаешь исходник в код и описываешь extensions в setup.py и оттуда setuptools питона их собирает, там по сути прямой интерфейс к компилятору. Дальше когда публикуешь - выкладываешь wheel и sdist, по сути бинари и исходники. Для кого есть колёса - качает wheel, иначе собирает сам (pip это автоматом делает)

upcFrost ★★★★★
()

Я собираю по старинке через setuptools.Extension. wheel’ы не делаю, потому что делают и используют их только конченые. pip замечательно ставит модуль из исходников и собирает всё с системными библиотеками.

slovazap ★★★★★
()
Ответ на: комментарий от upcFrost

Обычно ты пихаешь исходник в код и описываешь extensions в setup.py и оттуда setuptools питона их собирает, там по сути прямой интерфейс к компилятору.

Setup.py выходит из употребления. Изначальная идея его заключалась в том, что твое окружение идеально совпадает с окружением разраба, ты просто запускаешь python3 setup.py build и python3 setup.py install — и всё.

Собственно, для PSO я не заморачивался и сделал по старинке. Но для чуть более сложного проекта уже не прокатывает, потому что
а. нужно поставить программы-зависимости;
b. нужно поставить пакеты-зависимости;
c. нужно адаптироваться под полученные зависимости (этот этап можно навелосипедить на setup.py);
d. теперь проект можно собрать и развернуть.

Если тебе нужно собрать цепочку пакетов (например, на базе numpy), то это на целый день. Для описания этапов, выходящих за пределы сборки одного единственного пакета, в том числе навелосипедили setup.cfg, и может быть сделали бы еще кучу конфигов, но в итоге это дело унифицировали в pyproject.toml — не прошло и 20 лет, чтобы понять, что «система сборки собирает софт», а не «питон собирает что может, потом возможно дергает систему сборки, которая собирает то, что питон не смог собрать сам». Я могу понять изначальную задумку плана «все библиотеки питона будут писаться на самом питоне, потому пакетировать мы будем только платформонезависимые питоновые сорцы» — но уже в конце 90-х стало ясно, что эта схема не работает, что на любой чих и пук в питоне нужно писать сишное расширение.

Еще раз прошу мне напомнить про гениальность Гвидо, как диктатора-архитектора.

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 1)