Первый вариант идеален в некоторых случаях (как минимум, чтобы у нативного кода не было дополнительных зависимостей). Во всех прочих случаях приходится использовать второй вариант.
12 мая 2012 г., 23:22 пользователь Vladimir Timofeev <[email protected]>написал: > 12 мая 2012 г., 21:58 пользователь Ivan Petrov > <[email protected]> написал: > > вот когда просто на 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 > > [email protected] | http://moscow.pm.org > > > > -- > Vladimir Timofeev <[email protected]> > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
