35.17. Инфраструктура создания расширений#
35.17. Инфраструктура создания расширений
Если вы думаете о распространении своих модулей расширения Tantor SE-1С, настройка портативной системы сборки для них может быть довольно сложной. Поэтому установка Tantor SE-1С предоставляет инфраструктуру сборки для расширений, называемую PGXS, чтобы простые модули расширения могли быть построены просто на уже установленном сервере. PGXS предназначен в основном для расширений, включающих код на C, хотя его можно использовать и для расширений, состоящих только из SQL. Обратите внимание, что PGXS не предназначен для универсальной системы сборки, которая может использоваться для сборки любого программного обеспечения, взаимодействующего с Tantor SE-1С; он просто автоматизирует общие правила сборки для простых модулей расширения сервера. Для более сложных пакетов вам может потребоваться написать свою собственную систему сборки.
Для использования инфраструктуры 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
.controlprefix
/share/extensionMODULEDIR
подкаталог
, в который должны быть установлены файлы DATA и DOCS (если не задано, по умолчанию используетсяprefix
/shareextension
, еслиEXTENSION
установлен, илиcontrib
, если нет)DATA
случайные файлы для установки в
prefix
/share/$MODULEDIRDATA_built
Установите все файлы в случайном порядке в каталог
, которые необходимо сначала скомпилировать.prefix
/share/$MODULEDIRDATA_TSEARCH
случайные файлы для установки в каталог
prefix
/share/tsearch_dataDOCS
случайные файлы для установки в каталог
prefix
/doc/$MODULEDIRHEADERS
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
/binSCRIPTS_built
Установите скриптовые файлы (не бинарные) в каталог
, которые необходимо сначала скомпилировать.prefix
/binREGRESS
список тестовых случаев регрессии (без суффикса), см. ниже
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
SHLIB_LINK
будет добавлено в строку ссылки
MODULE_big
PG_CONFIG
путь к программе pg_config для установки Tantor SE-1С для сборки (обычно просто
pg_config
для использования первого вPATH
)
Поместите данный сборочный файл Makefile
в каталог, который содержит ваше расширение. Затем вы можете выполнить make
для компиляции и make install
для установки вашего модуля. По умолчанию расширение компилируется и устанавливается для установки Tantor SE-1С, соответствующей первой программе 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-1С. Файлы скриптов, перечисленные в переменной REGRESS
, должны находиться в подкаталоге с именем sql/
в каталоге вашего расширения. Эти файлы должны иметь расширение .sql
, которое не должно быть включено в список REGRESS
в файле makefile. Для каждого теста также должен быть файл с ожидаемым выводом в подкаталоге с именем expected/
, с тем же именем и расширением .out
. Команда make installcheck
выполняет каждый тестовый скрипт с помощью утилиты psql и сравнивает полученный вывод с соответствующим ожидаемым файлом. Любые различия будут записаны в файл regression.diffs
в формате diff -c
. Обратите внимание, что попытка запустить тест, для которого отсутствует ожидаемый файл, будет отмечена как “проблема”, поэтому убедитесь, что у вас есть все ожидаемые файлы.
Скрипты, перечисленные в переменной ISOLATION
, используются для тестирования поведения параллельных сессий с вашим модулем, которые можно вызвать с помощью команды make installcheck
после выполнения команды make install
. Для этого должен быть запущен сервер Tantor SE-1С. Файлы скриптов, перечисленные в переменной 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/
, если они соответствуют ожидаемым результатам теста.