35.17. Инфраструктура создания расширений#

35.17. Инфраструктура создания расширений

35.17. Инфраструктура создания расширений #

Если вы думаете о распространении своих модулей расширения Tantor SE-1C, настройка портативной системы сборки для них может быть довольно сложной. Поэтому установка Tantor SE-1C предоставляет инфраструктуру сборки для расширений, называемую PGXS, чтобы простые модули расширения могли быть построены просто на уже установленном сервере. PGXS предназначен в основном для расширений, включающих код на C, хотя его можно использовать и для расширений, состоящих только из SQL. Обратите внимание, что PGXS не предназначен для универсальной системы сборки, которая может использоваться для сборки любого программного обеспечения, взаимодействующего с Tantor SE-1C; он просто автоматизирует общие правила сборки для простых модулей расширения сервера. Для более сложных пакетов вам может потребоваться написать свою собственную систему сборки.

Для использования инфраструктуры PGXS для вашего расширения, необходимо написать простой makefile. В makefile вам нужно установить некоторые переменные и включить глобальный makefile PGXS. Вот пример, который создает модуль расширения с именем isbn_issn, состоящий из общей библиотеки, содержащей некоторый код на языке C, файла управления расширением, SQL-скрипта, файла включения (требуется только в случае, если другие модули могут обращаться к функциям расширения без использования SQL) и текстового файла документации.

MODULES = isbn_issn
EXTENSION = isbn_issn
DATA = isbn_issn--1.0.sql
DOCS = README.isbn_issn
HEADERS_isbn_issn = isbn_issn.h

PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)

Последние три строки всегда должны быть одинаковыми. Ранее в файле вы назначаете переменные или добавляете пользовательские правила make.

Установите одну из этих трех переменных, чтобы указать, что нужно построить:

MODULES #

список объектов общей библиотеки, которые будут созданы из исходных файлов с тем же корнем (не включайте суффиксы библиотек в этот список)

MODULE_big #

библиотека, общая для построения из нескольких исходных файлов (перечислите объектные файлы в OBJS)

PROGRAM #

исполняемая программа для сборки (перечислить объектные файлы в OBJS)

Следующие переменные также могут быть установлены:

EXTENSION #

имя(имена) расширения; для каждого имени необходимо предоставить файл extension.control, который будет установлен в prefix/share/extension

MODULEDIR #

подкаталог prefix/share, в который должны быть установлены файлы DATA и DOCS (если не задано, по умолчанию используется extension, если EXTENSION установлен, или contrib, если нет)

DATA #

случайные файлы для установки в prefix/share/$MODULEDIR

DATA_built #

Установите все файлы в случайном порядке в каталог prefix/share/$MODULEDIR, которые необходимо сначала скомпилировать.

DATA_TSEARCH #

случайные файлы для установки в каталог prefix/share/tsearch_data

DOCS #

случайные файлы для установки в каталог prefix/doc/$MODULEDIR

HEADERS
HEADERS_built #

Файлы для (при необходимости сборки и) установки в каталоге prefix/include/server/$MODULEDIR/$MODULE_big.

В отличие от DATA_built, файлы в HEADERS_built не удаляются целью clean; если нужно удалить их, также добавьте их в EXTRA_CLEAN или добавьте свои собственные правила для этого.

HEADERS_$MODULE
HEADERS_built_$MODULE #

Файлы для установки (после сборки, если указано) находятся в каталоге prefix/include/server/$MODULEDIR/$MODULE, где $MODULE должно быть именем модуля, используемым в MODULES или MODULE_big.

В отличие от DATA_built, файлы в HEADERS_built_$MODULE не удаляются целью clean; если нужно удалить их, также добавьте их в EXTRA_CLEAN или добавьте свои собственные правила для этого.

Это допустимо использовать оба переменных для одного модуля или любую комбинацию, если у вас есть два имени модуля в списке MODULES, которые отличаются только наличием префикса built_, что может вызвать неоднозначность. В этом (надеюсь, маловероятном) случае следует использовать только переменные HEADERS_built_$MODULE.

SCRIPTS #

Установите скриптовые файлы (не бинарные) в каталог prefix/bin.

SCRIPTS_built #

Установите скриптовые файлы (не бинарные) в каталог prefix/bin, которые необходимо сначала скомпилировать.

REGRESS #

список тестовых случаев регрессии (без суффикса), см. ниже

REGRESS_OPTS #

дополнительные переключатели для передачи в pg_regress

ISOLATION #

список изоляционных тестовых случаев, см. ниже для получения более подробной информации

ISOLATION_OPTS #

дополнительные переключатели для передачи в pg_isolation_regress

TAP_TESTS #

переключатель, определяющий, нужно ли запускать тесты TAP, см. ниже

NO_INSTALL #

Не определяйте цель install, полезную для тестовых модулей, которым не требуется установка их продуктов сборки.

NO_INSTALLCHECK #

Не определяйте цель installcheck, полезно, например, если тесты требуют специальной конфигурации, или не используйте pg_regress.

EXTRA_CLEAN #

дополнительные файлы для удаления в make clean

PG_CPPFLAGS #

Будет добавлено перед CPPFLAGS

PG_CFLAGS #

будет добавлено к CFLAGS

PG_CXXFLAGS #

будет добавлено к CXXFLAGS

PG_LDFLAGS #

будет добавлено к LDFLAGS

PG_LIBS #

будет добавлено в строку ссылки PROGRAM

будет добавлено в строку ссылки MODULE_big

PG_CONFIG #

путь к программе pg_config для установки Tantor SE-1C для сборки (обычно просто pg_config для использования первого в PATH)

Поместите данный сборочный файл Makefile в каталог, который содержит ваше расширение. Затем вы можете выполнить make для компиляции и make install для установки вашего модуля. По умолчанию расширение компилируется и устанавливается для установки Tantor SE-1C, соответствующей первой программе pg_config, найденной в вашем PATH. Вы можете использовать другую установку, установив переменную PG_CONFIG, указывающую на программу pg_config, либо внутри makefile, либо в командной строке make.

Также можно запустить make в каталоге, находящемся вне исходного дерева вашего расширения, если нужно сохранить отдельный каталог сборки. Эта процедура также называется VPATH build. Вот как:

mkdir build_dir
cd build_dir
make -f /path/to/extension/source/tree/Makefile
make -f /path/to/extension/source/tree/Makefile install

В качестве альтернативы, вы можете настроить каталог для сборки с использованием VPATH аналогично тому, как это делается для основного кода. Один из способов сделать это - использовать скрипт ядра config/prep_buildtree. После выполнения этого действия вы можете собрать, установив переменную make VPATH следующим образом:

make VPATH=/path/to/extension/source/tree
make VPATH=/path/to/extension/source/tree install

Эта процедура может работать с большим разнообразием структур каталогов.

Скрипты, перечисленные в переменной REGRESS, используются для регрессионного тестирования вашего модуля, которое может быть вызвано с помощью команды make installcheck после выполнения команды make install. Для этого необходимо иметь работающий сервер Tantor SE-1C. Файлы скриптов, перечисленные в переменной REGRESS, должны находиться в подкаталоге с именем sql/ в каталоге вашего расширения. Эти файлы должны иметь расширение .sql, которое не должно быть включено в список REGRESS в файле makefile. Для каждого теста также должен быть файл с ожидаемым выводом в подкаталоге с именем expected/, с тем же именем и расширением .out. Команда make installcheck выполняет каждый тестовый скрипт с помощью утилиты psql и сравнивает полученный вывод с соответствующим ожидаемым файлом. Любые различия будут записаны в файл regression.diffs в формате diff -c. Обратите внимание, что попытка запустить тест, для которого отсутствует ожидаемый файл, будет отмечена как проблема, поэтому убедитесь, что у вас есть все ожидаемые файлы.

Скрипты, перечисленные в переменной ISOLATION, используются для тестирования поведения параллельных сессий с вашим модулем, которые можно вызвать с помощью команды make installcheck после выполнения команды make install. Для этого должен быть запущен сервер Tantor SE-1C. Файлы скриптов, перечисленные в переменной ISOLATION, должны находиться в подкаталоге specs/ в каталоге вашего расширения. Эти файлы должны иметь расширение .spec, которое не должно быть включено в список ISOLATION в файле makefile. Для каждого теста также должен быть файл с ожидаемым выводом в подкаталоге expected/ с тем же именем и расширением .out. Команда make installcheck выполняет каждый тестовый скрипт и сравнивает полученный вывод с соответствующим ожидаемым файлом. Любые различия будут записаны в файле output_iso/regression.diffs в формате diff -c. Обратите внимание, что попытка запустить тест, для которого отсутствует ожидаемый файл, будет отображена как проблема, поэтому убедитесь, что у вас есть все ожидаемые файлы.

TAP_TESTS enables the use of TAP tests. Data from each run is present in a subdirectory named tmp_check/

Подсказка

Самый простой способ создать ожидаемые файлы - это создать пустые файлы, затем выполнить тестовый запуск (который, конечно же, сообщит о различиях). Осмотрите фактические файлы результатов, найденные в каталоге results/ (для тестов в REGRESS), или в каталоге output_iso/results/ (для тестов в ISOLATION), затем скопируйте их в каталог expected/, если они соответствуют ожидаемым результатам теста.