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

[Alexandr Alexeev]

Мне кажется, тесты должны быть модульными, то есть для всего, что не входит
в модуль, должны быть заглушки/mock-объекты.

12 мая 2012 г., 23:52 пользователь Akzhan Abdulin
<akzhan.abdulin на gmail.com>написал:

> Первый вариант идеален в некоторых случаях (как минимум, чтобы у нативного
> кода не было дополнительных зависимостей).
> Во всех прочих случаях приходится использовать второй вариант.
>
> 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
>>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>


-- 
С уважением, Александр
Личный блог: http://eax.me/
Мой форум: http://it-talk.org/
Мой Twitter: http://twitter.com/afiskon
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20120513/513abe81/attachment-0001.html>