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
