Вход:  Пароль:  
FreeSource: AltLinux/Sisyphus/ruby ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

Ruby


Основные правила сборки приложений и модулей ruby изложены в Ruby Packaging Policy. Цель же этого документа – об'яснить на простых примерах как следует поступать в различных ситуациях а также показать как можно собирать простые модули.


Я не рассматриваю rubygems, так как эта система включает в себя свой пакетный менеджер, не совместимый с дистрибутивным. Про отношение Debian к rubygems можно прочитать тут, рекомендации апстриму изложены тут. У нас ситуация в общем аналогичная.


Тут пока находится поток сознания, который я буду приводить к нормальному виду.


Оглавление документа

Общие принципы сборки модулей


Есть два способа сборки модулей. При помощи rubygems (который мы не рассматриваем по ряду причин), и «нативная» сборка, с помещением файлов в специальные каталоги, которые находятся в $LOAD_PATH.


Сборка пакета включает в себя:



Модули устанавливаются в так называемый vendor dir. В ALT Linux это /usr/share/ruby/vendor_ruby/RUBY.VERSION и /usr/lib/ruby/RUBY.VERSION/ARCHITECTURE. Поскольку по умолчанию установка модулей идёт в site dir, при сборке пакета надо использовать модуль vendor_specific, вызывая интерпретатор ruby как ruby -rvendor_specific. Для этого есть макрос %ruby.

Внутри тарбола


Внутри тарбола с модулем (или программой) могут находиться следующие файлы и каталоги:



Также как правило присутствует один или несколько «сценариев сборки», о них расскажу далее.

Собираем модуль


Существует несколько, различного уровня «стандартности», способов сборки модулей ruby.

extconf.rb AKA MkMf


Аналог configure, использует модуль mkmf, входящий в стандартную поставку ruby. Внутри скрипта проверяется наличие необходимых заголовочных файлов и библиотек, на выходе генерится Makefile, который обрабатывается стандартным make. Используется только в тех проектах, где есть бинарные модули. Если «рядом» с extconf.rb находится файл depend, его содержимое добавляется к Makefile. Исходные тексты и заголовочные файлы бинарного модуля как правило тоже лежат «рядом» с extconf.rb.


Типичные секции %build и %install выглядят следующим образом:


setup.rb имени Minero Aoki


Скрипт сборки и установки общего назначения. Как правило используется для сборки и установки pure-ruby модулей. Имеет некоторое количество стандартных опций, может собирать бинарные модули, находящиеся в каталоге ext/ (как правило там присутствует extconf.rb, см. выше).


Типичные секции %build и %install выглядят следующим образом:


install.rb


Иногда это самописный скрипт, иногда встречается одна из первых версий setup.rb. Как правило используется только для установки pure-ruby модулей. Стандартных макросов для поддержки install.rb нет.

Rakefile и остальные случаи


Сценарий для rake. Обычно может иметь task'и build (если есть бинарные модули) и test, но последнее время не имеет task'а install. Зато использует rubygems.


Для вызова rake и rake install есть два стандартных макроса %rake и %rake_install соответственно.


Если task install не определён или вообще отсутствует установочный скрипт (в случае pure-ruby модуля), можно использовать setup.rb из пакета ruby-tool-setup примерно следующим образом:



Далее используются макросы %ruby_config, %ruby_build и %ruby_install.

Пакуем документацию


Документация в формате RI генерируется при помощи утилиты rdoc, находящейся в пакете ruby-tool-rdoc. Для этого существует стандартный макрос %rdoc предназначенный для использования в секции %install (обычно одной из последних строк). В качестве аргументов этого макроса перечисляются файлы и каталоги с исходниками и при необходимости другие опции утилиты rdoc.


Для pure-ruby модулей как правило используется конструкция:



Если присутствуют бинарные модули:



Документацию желательно паковать в подпакет %name-doc. При этом паковать следует только документацию для основных классов модуля, описание расширений сторонних классов паковать не нужно.

Складываем файлы в пакеты


Pure-ruby модули помещаются в %ruby_sitelibdir, бинарные модули в %ruby_sitearchdir, документация в формате RI в %ruby_ri_sitedir (при этом файл %ruby_ri_sitedir/created.rid упаковывать не нужно).

Добро пожаловать в реальный мир


В теории всё выглядит красиво, однако на практике среднего размера модуль представляет собой «нечто», что может работать в любой помойке. Однако мы делаем не помойку, поэтому местечковые хаки нам не нужны.

Не загрязняем $LOAD_PATH ($:)


Очень часто в коде можно увидеть конструкции вида:



Эта конструкция добавляет в $LOAD_PATH некоторый путь. Сделано это для того, чтобы модуль (или исполняемый скрипт) можно было использовать из любого места. Поскольку в нашем случае все файлы пакуются в стандартные места, подобные конструкции не нужны. В большинстве случаев такие конструкции можно безболезненно удалить.

Используем существующие модули и размаскируем зависимости


Поскольку наша помойка не является «любой», её ТТХ нам известны. Например, известно что это Linux, есть Iconv и так далее. Поэтому специфичный код, предназначенный для работы на других платформах в наших пакетах не нужен (а иногда бывает и вреден, поскольку даже «мёртвый» код может порождать зависимости, которые в некоторых случаях превращаются в unmet'ы).


Также мы можем превратить опциональную зависимость в явную. Пример:



В данном случае всю эту сложную конструкцию можно заменить на одну строку require 'iconv'. Как бонус мы получаем зависимость на ruby(iconv) и полную функциональность данного модуля.


Реальные примеры можно посмотреть в пакете ruby-gettext.



 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]