Первый вариант идеален в некоторых случаях (как минимум, чтобы у нативного кода не было дополнительных зависимостей).<div>Во всех прочих случаях приходится использовать второй вариант.<br><br><div class="gmail_quote">12 мая 2012 г., 23:22 пользователь Vladimir Timofeev <span dir="ltr"><<a href="mailto:vovkasm@gmail.com" target="_blank">vovkasm@gmail.com</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">12 мая 2012 г., 21:58 пользователь Ivan Petrov<br>
<<a href="mailto:i.petro.77.00@gmail.com">i.petro.77.00@gmail.com</a>> написал:<br>
<div class="im">> вот когда просто на cpan модуль загружаем или когда XS-модуль без<br>
> зависимостей загружаем, то в итоге множество хостов его тестируют и<br>
> если что-то не так, то присылают письма.<br>
><br>
> а вот если XS-модуль зависит от какой-то библиотеки, скажем libabc.so,<br>
> то как правильно оформить модуль? не прикладывать же исходники libabc?<br>
<br>
</div>Есть много мнений ))<br>
<br>
Вот эти модули поставляются вместе с исходниками сторонних библиотек:<br>
* EV<br>
* Alien::SVN<br>
<br>
А вот эти, к примеру, нет:<br>
* XML::LibXML<br>
* Net::SSLeay<br>
<br>
=> Правильного решения не существует.<br>
<br>
Я вижу такие особенности этих двух вариантов.<br>
Если поставлять исходный код библиотеки вместе с модулем, то:<br>
+ Можно модифицировать код, вставлять свои патчи, к примеру.<br>
+ Установка может быть проще для конечного пользователя.<br>
+ Можно рассчитывать свой модуль на конкретную версию библиотеки, не<br>
надо поддерживать изменения в API.<br>
+ Можно линковать стороннюю библиотеку статически (что повышает скорость)<br>
- Дистрибутив раздувается (иногда очень сильно) по размеру.<br>
- Приходится самому писать (и, главное, поддерживать) систему сборки<br>
сторонней библиотеки у конечного пользователя со всеми вытекающими<br>
win,vms, зоопарком компиляторов и т.п.<br>
- Сторонняя библиотека тоже может зависеть от других библиотек, а еще<br>
от окружения (см. п. выше)<br>
- Гораздо больше сил приходится тратить на поддержку, т.к. каждая<br>
новая версия библиотеки влечет новую версию модуля на CPAN<br>
- Лицензия сторонней библиотеки может затруднить или сделать<br>
невозможным её включение в дистрибутив модуля<br>
<br>
Если модуль ожидает, что нужная библиотека уже есть в системе пользователя, то:<br>
+ Не паримся мелкими версиями (пока API совместимо, у нас все будет работать)<br>
+ Система сборки становится сильно проще (все проблемы по установке<br>
библиотеки лежат на пользователе)<br>
+ Остальные минусы из первого варианта исчезают ;-)<br>
- Все же приходится писать систему для обнаружения библиотеки у пользователя:<br>
  - Найти, если нет, выдать приемлемое сообщение об ошибке (и для<br>
пользователя и еще CPAN тестерами озаботиться...)<br>
  - Если нашли, угадать ключи компиляции/линковки, которые нам надо<br>
добавить для сборки...<br>
  - Проверить версию, поддерживаемая ли...<br>
<br>
Как то так. Лично я склоняюсь ко второму варианту, он попроще для разработчика.<br>
Конечно будет совсем здорово, если у Perl появится стандартная система<br>
описать внешние зависимости у CPAN-модуля, но пока её нет, к<br>
сожалению.<br>
<div class="im HOEnZb"><br>
> --<br>
> Moscow.pm mailing list<br>
> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
<br>
<br>
<br>
</div><span class="HOEnZb"><font color="#888888">--<br>
Vladimir Timofeev <<a href="mailto:vovkasm@gmail.com">vovkasm@gmail.com</a>><br>
</font></span><div class="HOEnZb"><div class="h5">--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</div></div></blockquote></div><br></div>