Если вы планируете распространять свои Digital Q.DataBase модули расширения, создание для них переносимой системы сборки может оказаться довольно сложной задачей. Поэтому в составе Digital Q.DataBase поставляется инфраструктура сборки расширений, называемая PGXS, которая позволяет собирать простые модули расширения для уже установленного сервера. PGXS в основном предназначена для расширений, включающих код на языке C, хотя она может использоваться и для расширений на чистом SQL. Обратите внимание, что PGXS не является универсальной средой сборки для любого программного обеспечения, взаимодействующего с Digital Q.DataBase; она лишь автоматизирует стандартные правила сборки простых серверных модулей расширения. Для более сложных пакетов может потребоваться разработка собственной системы сборки.
Чтобы использовать PGXS инфраструктуру для своего расширения,
необходимо написать простой makefile.
В этом файле следует задать несколько переменных
и включить глобальный PGXS makefile.
Ниже приведен пример сборки модуля расширения под названием
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 #
имя (имена) расширения; для каждого имени необходимо предоставить
файл,
который будет установлен в
расширение.controlпрефикс/share/extension
MODULEDIR #
подкаталог
в который должны быть установлены файлы DATA и DOCS
(если не задано, по умолчанию используется префикс/shareрасширение если
EXTENSION установлено,
или contrib если нет)
DATA #
произвольные файлы для установки в префикс/share/$MODULEDIR
DATA_built #
произвольные файлы для установки в
,
которые необходимо предварительно собрать
префикс/share/$MODULEDIR
DATA_TSEARCH #
произвольные файлы для установки в
префикс/share/tsearch_data
DOCS #
произвольные файлы для установки в
префикс/doc/$MODULEDIR
HEADERSHEADERS_built #
Файлы для (необязательной сборки и) установки в
.
префикс/include/server/$MODULEDIR/$MODULE_big
В отличие от DATA_built, файлы в HEADERS_built
не удаляются при выполнении цели clean target; если их требуется удалить,
также добавьте их в EXTRA_CLEAN или добавьте собственные правила для выполнения этой операции.
HEADERS_$MODULEHEADERS_built_$MODULE #
Файлы, подлежащие установке (при необходимости после сборки), в каталог
,
где префикс/include/server/$MODULEDIR/$MODULE$MODULE должно соответствовать имени модуля, используемому
в MODULES или MODULE_big.
В отличие от DATA_built, файлы в HEADERS_built_$MODULE
не удаляются при выполнении цели clean target; если их требуется удалить,
также добавьте их в EXTRA_CLEAN или добавьте собственные правила для выполнения этой операции.
Допускается использование обеих переменных для одного и того же модуля или любого их
сочетания, кроме случаев, когда в списке присутствуют два имени модулей,
MODULES различающиеся только наличием
префикса built_, что приведет к неоднозначности. В
этом (надеемся, маловероятном) случае следует использовать только
HEADERS_built_$MODULE переменные.
SCRIPTS #
файлы сценариев (не исполняемые файлы) для установки в
префикс/bin
SCRIPTS_built #
файлы сценариев (не исполняемые файлы) для установки в
,
которые необходимо предварительно собрать
префикс/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 строку компоновки
SHLIB_LINK #
будет добавлено в MODULE_big строку компоновки
PG_CONFIG #
путь к pg_config программа для
Digital Q.DataBase экземпляра установки, для которого выполняется сборка
(обычно просто pg_config для использования первого найденного в вашей переменной
PATH)
Разместите этот makefile под именем Makefile в директории,
в которой находится ваше расширение. Затем вы можете выполнить
make для компиляции, а затем make
install для установки вашего модуля. По умолчанию расширение компилируется и устанавливается для той
Digital Q.DataBase инсталляции, которая соответствует первой pg_config программе
найденной в вашем PATH. Вы можете использовать другую инсталляцию,
установив значение PG_CONFIG так, чтобы оно указывало на её
pg_config программу либо в make-файле,
либо в make командной строке.
Вы также можете запустить make в директории вне дерева исходных кодов
вашего расширения, если хотите хранить директорию сборки отдельно.
Эта процедура также называется
VPATH
сборкой. Порядок действий:
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. Для корректной работы
необходимо наличие запущенного Digital Q.DataBase сервера.
Файлы сценариев, перечисленные в REGRESS должны находиться в
подкаталоге с именем sql/ в каталоге расширения.
Данные файлы должны иметь расширение .sql, которое не следует
включать в REGRESS список в make-файле. Для каждого теста также должен существовать файл, содержащий ожидаемый результат, в подкаталоге с именем expected/также должен присутствовать файл с ожидаемым результатом, имеющий то же основное имя и
расширение .out. make installcheck
запускает каждый тестовый сценарий с использованием psqlи сравнивает
полученный результат с соответствующим эталонным файлом. Любые расхождения будут записаны в файл regression.diffs в формате
diff -c format. Обратите внимание, что попытка выполнения теста при отсутствии файла с ожидаемым результатом будет зафиксирована как «trouble», поэтому убедитесь в наличии всех необходимых эталонных файлов.
Сценарии, перечисленные в ISOLATION используются
для тестов, проверяющих работу параллельных сессий с вашим модулем, которые
можно инициировать с помощью make installcheck после выполнения
make install. Для обеспечения корректной работы необходимо наличие запущенного экземпляра Digital Q.DataBase сервер. Файлы сценариев,
указанные в ISOLATION должны находиться в подкаталоге
с именем specs/ в каталоге вашего расширения. Эти файлы
должны иметь расширение .spec, которое не следует включать
в ISOLATION список в make-файле. Для каждого теста также должен существовать файл, содержащий ожидаемый результат, в подкаталоге с именем expected/также должен присутствовать файл с ожидаемым результатом, имеющий то же основное имя и
расширение .out. make installcheck
выполняет каждый сценарий тестирования и сравнивает полученный результат с соответствующим эталонным файлом. Все различия будут записаны в файл
output_iso/regression.diffs в
diff -c format. Обратите внимание: попытка запуска теста, для которого отсутствует эталонный файл, будет отмечена как «trouble», поэтому убедитесь в наличии всех эталонных файлов.
TAP_TESTS позволяет использовать TAP-тесты. Данные каждого запуска находятся в подкаталоге с именем tmp_check/.
Самый простой способ создания ожидаемых файлов заключается в создании пустых файлов с последующим выполнением тестового запуска (который, разумеется, выявит различия). Проверьте
фактические файлы результатов, находящиеся в results/
каталоге (для тестов в REGRESS), или
output_iso/results/ каталоге (для тестов в
ISOLATION), а затем скопируйте их в
expected/ если они соответствуют ожидаемым результатам теста.