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

[Akzhan Abdulin]

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

12 мая 2012 г., 23:22 пользователь Vladimir Timofeev <vovkasm на gmail.com>написал:

> 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 mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20120512/2b5cae9a/attachment.html>