[Moscow.pm] XS-модули и автотестирование на cpan

Vladimir Timofeev vovkasm на gmail.com
Сб Май 12 12:22:41 PDT 2012


12 мая 2012 г., 21:58 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com> написал:
> вот когда просто на cpan модуль загружаем или когда XS-модуль без
> зависимостей загружаем, то в итоге множество хостов его тестируют и
> если что-то не так, то присылают письма.
>
> а вот если XS-модуль зависит от какой-то библиотеки, скажем libabc.so,
> то как правильно оформить модуль? не прикладывать же исходники libabc?

Есть много мнений ))

Вот эти модули поставляются вместе с исходниками сторонних библиотек:
* EV
* Alien::SVN

А вот эти, к примеру, нет:
* XML::LibXML
* Net::SSLeay

=> Правильного решения не существует.

Я вижу такие особенности этих двух вариантов.
Если поставлять исходный код библиотеки вместе с модулем, то:
+ Можно модифицировать код, вставлять свои патчи, к примеру.
+ Установка может быть проще для конечного пользователя.
+ Можно рассчитывать свой модуль на конкретную версию библиотеки, не
надо поддерживать изменения в API.
+ Можно линковать стороннюю библиотеку статически (что повышает скорость)
- Дистрибутив раздувается (иногда очень сильно) по размеру.
- Приходится самому писать (и, главное, поддерживать) систему сборки
сторонней библиотеки у конечного пользователя со всеми вытекающими
win,vms, зоопарком компиляторов и т.п.
- Сторонняя библиотека тоже может зависеть от других библиотек, а еще
от окружения (см. п. выше)
- Гораздо больше сил приходится тратить на поддержку, т.к. каждая
новая версия библиотеки влечет новую версию модуля на CPAN
- Лицензия сторонней библиотеки может затруднить или сделать
невозможным её включение в дистрибутив модуля

Если модуль ожидает, что нужная библиотека уже есть в системе пользователя, то:
+ Не паримся мелкими версиями (пока API совместимо, у нас все будет работать)
+ Система сборки становится сильно проще (все проблемы по установке
библиотеки лежат на пользователе)
+ Остальные минусы из первого варианта исчезают ;-)
- Все же приходится писать систему для обнаружения библиотеки у пользователя:
  - Найти, если нет, выдать приемлемое сообщение об ошибке (и для
пользователя и еще CPAN тестерами озаботиться...)
  - Если нашли, угадать ключи компиляции/линковки, которые нам надо
добавить для сборки...
  - Проверить версию, поддерживаемая ли...

Как то так. Лично я склоняюсь ко второму варианту, он попроще для разработчика.
Конечно будет совсем здорово, если у Perl появится стандартная система
описать внешние зависимости у CPAN-модуля, но пока её нет, к
сожалению.

> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org



-- 
Vladimir Timofeev <vovkasm на gmail.com>


Подробная информация о списке рассылки Moscow-pm