2012-03-15 1 views
2

У меня есть требование разработать группу модулей Perl для внутренней работы. Я хотел бы, чтобы все они были сформированы в одном семье или набор модулей, а не отдельный.Советы по разработке набора модулей Perl

Например, пакет будет что-то вроде:

MySuite::App::Module1 
      ::Module2 
MySuite::Env 
MySuite::Utils::Logger 
       ::Util2 

Я прошел через perlmodstyle, perlnewmod и т.д., но все они, кажется, сосредотачиваются на кончиках для разработки отдельных модулей. Каковы советы/рекомендации по разработке/распределению такого пакета? (отдельные модули в наборе могут быть написаны разными разработчиками)

+0

Я работал с Perl в течение некоторого времени, и мой совет: переход на Python :) –

+0

То, о чем вы говорите, известно как * Распределение модулей * в Perl; что также может помочь в поиске. –

ответ

2

Это не сильно отличается от одномодульных распределений. Два дополнительных установленные конвенции являются:

  1. Место модули иерархически в директории lib.

    MySuite::App::Module1  → lib/MySuite/App/Module1.pm 
    MySuite::App::Module2  → lib/MySuite/App/Module2.pm 
    MySuite::Env    → lib/MySuite/Env.pm 
    MySuite::Utils::Logger  → lib/MySuite/Utils/Logger.pm 
    MySuite::Utils::Util2  → lib/MySuite/Utils/Utils2.pm 
    
  2. Выберите главный модуль, который станет именем распространения. Ваш пример выглядит так, как будто он должен иметь дополнительный lib/MySuite.pm с заявлением пакета MySuite и небольшим количеством кода и некоторой документацией о точке входа. Назначьте этот модуль как module_name в файле Build.PL.


Для получения дополнительной информации на упаковке в целом, см:

Обратная связь/критика на ваш прогресс в зонах общественного пользования Lable от:

+0

Спасибо за ответ. Цените, если вы можете прояснить следующее немного больше. (a) Когда я использую Module :: Starter, он генерирует Makefile.PL, а не Build.PL. Они одинаковы? (b) Module :: Starter помещает каждый модуль под отдельный корневой каталог, если они создаются в разное время. Что нужно сделать, чтобы перенести их в корневой каталог исходного пакета? (c) Любая идея о том, как тесты должны быть написаны при объединении модулей, как в (b)? Спасибо за ваше время. – Upendra

+0

⒜ Makefile.PL и Build.PL не совпадают (разные API), но выполняют ту же задачу. ⒝ Переместите подкаталоги 'lib',' t', 'script' в базовый каталог набора. Слейте файл Build/README/distro metafiles в эквивалентные файлы в базовом каталоге набора. ⒞ Поскольку тестирование по умолчанию запускает все файлы 't/*. T', никакая работа не требуется, кроме перемещения тестовых файлов, как я только что написал. – daxim

1

Используйте инструмент h2xs командной строки поставляется с Perl. Он создаст очень полезный скелет модуля perl (который особенно подходит для распространения в CPAN). Введите в оболочке:

$ h2xs -X MySuite

Это позволит создать единое распределение с этим конкретным модулем скелетом, помещенным в Lib. Изучите его и создайте другие .pm-файлы по мере необходимости ниже lib. Изучите строку «package» в источнике и сопоставьте путь к файлу; вы должны получить основную идею. Например:

$ cd MySuite 
    $ touch -p lib/MySuite/App/Module.pm 
    $ touch -p lib/MySuite/Env.pm 
    $ ... 

будет основным шагом для добавления дополнительных модулей в ваш дистрибутив.Каждый раз, когда вы добавить еще один файл .pm или изменить имена файлов, выдать

$ perl Makefile.PL (only first time or "Makefile" not present) 
    $ make manifest 

синхронизировать файл манифеста; он добавит все файлы в дистрибутив модуля. Это позволяет использовать

$ make dist 

для создания архива MySuite-0.1.tar.gz. Наконец, вы можете проверить свой пакет с:

$ make test 

Вместе, h2xs очень удобно для авторов модулей и берет бремя подготовки базовой инфраструктуры распределения модуля. Он создает заполнители для заполнения конкретной документации и создает Makefile для управления вашим дистрибутивом - по мере роста, вы это оцените. Отправьте свой модуль в CPAN, и вам будет приятно, что он будет проиндексирован.