задачу перепакетирования, например для создания Linux-дистрибутива). Решать вам.
Половина дела будет сделана, если вы скопируете все файлы в нужные места. Вы должны организовать свой архив простым и разумным образом (создав каталоги с предопределенными именами).
Предположим, что дистрибутив содержит единственный пакет в архиве (наиболее распространенный случай). Тогда дерево каталогов организуется примерно так (причем файл setup.rb
помещается на верхний уровень).
top_level/
setup.rb
metaconfig (необязательно)
lib/
ext/
myext/
bin/
data/
conf/
man/
test/
Пустые каталоги можно опускать. Ниже описано назначение каждого каталога:
• lib
—программы на Ruby;
• ext
— расширения Ruby (написанные на С);
• myext
— имя расширения (на том же уровне могут располагаться и другие расширения); в каталоге каждого расширения должен находиться либо файл extconf.rb
, либо MANIFEST
;
• bin
— команды;
• data
— файлы данных;
• conf
— конфигурационные файлы;
• man
— страницы руководства;
• test
— автономные тесты и другие тестовые программы.
В общем случае эти файлы никак не обрабатываются, а просто копируются в нужное место. Но для специализированной настройки предусмотрены места подключения к каждому этапу процесса.
Три основных этапа — это config
, setup
и install
, вызываемые пользователем именно в таком порядке (на последнем шаге могут потребоваться полномочия root или, по крайней мере, выполнение sudo
).
Для подключения к этапу вы просто помещаете в нужный каталог написанную на Ruby программу с известным именем. Например, если необходимо перед обработкой сделать что-то нестандартное с файлом lib/foobar
, следует создать файл lib/foobar/pre-setup.rb
и поместить в него произвольный код.
Имя файла формируется следующим образом: префикс pre
или post
, дефис, имя задачи. Определены следующие имена задач: config
, setup
, install
, test
, clean
и dist-clean
.
В библиотеке setup.rb
есть понятия
Существует «API для подключения» (hook API), упрощающий решение ряда задач. Приведем некоторые определенные в нем методы:
• get_config_key(key)
— принимает в качестве параметра ключ и возвращает ассоциированное с ним значение (например, get_config('prefix')
возвращает путь, определенный с помощью конфигурационного параметра --prefix
);
• set_config_key(key, val)
— устанавливает значение конфигурационного параметра;
• config_key(key)
— то же, что get_config_key
;
• curr_srcdir
— текущий исходный каталог;
• curr_objdir
— текущий объектный каталог;
• srcfiles(rel_path='.')
— список всех файлов в каталоге с путем rel_path
(относительно текущего исходного каталога).
На верхнем уровне может находиться файл metaconfig
. Если он есть, то в нем задаются некоторые глобальные конфигурационные параметры. Для этой цели имеется специальный «metaconfig API» — небольшой набор вспомогательных методов, в частности:
• add_path_config(confname, default, description)
— определяет конфигурационный параметр, являющийся путем; задаются имя и значение по умолчанию. При вызове с флагом --help эта информация печатается;
• add_bool_config(confname, default, description)
— аналог add_path_config
, но описывается булевский параметр.
Дополнительную информацию по этим API можно найти в актуальной онлайновой документации.
17.2.2. Система RubyGems
Идея и название системы RubyGems принадлежат Райану Ливенгуду (Ryan Leavengood), но текущая реализация зародилась на ночной вечеринке, состоявшейся после Международной конференции по Ruby 2003 года в Остине, штат Техас. Первый вариант кода написали Чэд Фаулер (Chad Fowler), Джим Вайрих (Jim Weirich), Дэвид Алан Блэк (David Alan Black), Рич Килмер (Rich Kilmer) и Пол Брэннен (Paul Brannan). С тех пор к ним присоединились и другие; особо стоит отметить Эрика Ходеля (Eric Hodel) и Райана Дэвиса (Ryan Davis).
В настоящее время RubyGems, наверное, самая распространенная система создания пакетов, хотя до сих пор не включена в дистрибутив. Я полагаю, что после устранения нескольких мелких огрехов она станет настоящим стандартом для Ruby.
Как и повсюду в этой главе, мы рассматриваем вопрос с точки зрения разработчика. Вы узнаете, как представлять плоды своего труда в виде gem-пакета, но о манипулировании пакетами извне мы говорить не будем. Это тема другого раздела.
Возникает естественный вопрос: «Зачем нужно использовать gem-пакеты?» Вот перечень лишь некоторых их достоинств:
• простота установки и удаления;
• поддержка нескольких версий;
• управление зависимостями;
• механизм запроса и поиска пакетов.
Имя gem-пакета обычно состоит из короткого описательного слова, за которым следует дефис и стандартный номер версии в формате «основной.дополнительный.рабочий», который ныне принят почти повсеместно (конечно, каждая часть номера может состоять из нескольких цифр). Мы настоятельно рекомендуем пользоваться механизмом рациональной нумерации версии; если вы с ним не знакомы, поищите описание в сети.
Для построения gem-пакета нужно начать с создания предопределенного дерева каталогов (примерно такого же, как для setup
). На верхнем уровне неплохо поместить файл README, в который включаются информация об авторе и способе связи с ним, авторские права, лицензионное