39.17. Инфраструктура сборки расширений
Если вы задумываетесь о распространении ваших модулей расширения Postgres Pro, знайте, что организовать для них портируемую систему сборки может быть довольно сложно. Поэтому инсталляция Postgres Pro включает инфраструктуру сборки расширений, названную PGXS, так что несложные модули расширений можно собрать просто в среде установленного сервера. PGXS предназначена в первую очередь для расширений, написанных на C, хотя её можно применять и для расширения на чистом SQL. Заметьте, что PGXS не претендует на роль универсальной инфраструктуры сборки, способной собрать любой программный объект, взаимодействующий с Postgres Pro; она просто автоматизирует общие правила для сборки простых модулей расширения сервера. Для более сложных пакетов вам придётся разработать собственную систему сборки.
Чтобы использовать инфраструктуру PGXS для вашего расширения, вы должны написать простой сборочный файл. В нём вы должны установить нужные переменные и подключить глобальный сборочный файл 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имена расширений(я); для каждого имени вы должны предоставить файл
, который будет установлен врасширение.controlпрефикс/share/extensionMODULEDIRподкаталог в каталоге
, в который должны устанавливаться файлы DATA и DOCS (если не задан, подразумеваетсяпрефикс/shareextension, если установлена переменнаяEXTENSION, илиcontribв противном случае)DATAпроизвольные файлы, которые должны быть установлены в
префикс/share/$MODULEDIRDATA_builtпроизвольные файлы, которые должны быть сначала собраны, а затем установлены в
префикс/share/$MODULEDIRDATA_TSEARCHпроизвольные файлы, которые должны быть установлены в
префикс/share/tsearch_dataDOCSпроизвольные файлы, которые должны быть установлены в
префикс/doc/$MODULEDIRHEADERSHEADERS_builtФайлы, которые будут устанавливаться (и, возможно, собираться) в
.префикс/include/server/$MODULEDIR/$MODULE_bigВ отличие от файлов
DATA_built, файлы вHEADERS_builtне удаляются при выполнении целиclean; если вы хотите удалять их, добавьте их вEXTRA_CLEANили напишите собственные правила для этого.HEADERS_$MODULEHEADERS_built_$MODULEФайлы, которые будут устанавливаться (если требуется, после сборки) в
, где в качествепрефикс/include/server/$MODULEDIR/$MODULE$MODULEдолжно задаваться имя модуля, фигурирующее вMODULESилиMODULE_big.В отличие от файлов
DATA_built, файлы вHEADERS_built_$MODULEне удаляются при выполнении целиclean; если вы хотите удалять их, добавьте их вEXTRA_CLEANили напишите собственные правила для этого.Для одного модуля вполне можно использовать обе переменные в любом сочетании, если только в вашем списке
MODULESне присутствуют два имени, отличающиеся только префиксомbuilt_, что приводит к неоднозначности. В этом (очень маловероятном) случае следует использовать только переменныеHEADERS_built_$MODULE.SCRIPTSскрипты (не двоичные файлы), которые должны быть установлены в
префикс/binSCRIPTS_builtскрипты (не двоичные файлы), которые должны быть сначала собраны, а затем установлены в
префикс/binREGRESSсписок тестов регрессий (без суффикса), см. ниже
REGRESS_OPTSдополнительные параметры, передаваемые pg_regress
NO_INSTALLCHECKне определять цель
installcheck; это полезно, если тестам требуется особая конфигурация или pg_regress не используетсяEXTRA_CLEANдополнительные файлы, которые должны быть удалены при
make cleanPG_CPPFLAGSфлаги, добавляемые перед другими в
CPPFLAGSPG_CFLAGSфлаги, добавляемые в
CFLAGSPG_CXXFLAGSфлаги, добавляемые в
CXXFLAGSPG_LDFLAGSфлаги, добавляемые перед другими в
LDFLAGSPG_LIBSбудет добавлено в строку компоновки
PROGRAMSHLIB_LINKбудет добавлено в строку компоновки
MODULE_bigPG_CONFIGпуть к программе pg_config в инсталляции Postgres Pro, с которой будет выполняться сборка (обычно указывается просто
pg_config, и используется первый экземпляр, найденный по пути вPATH)
Поместите этот сборочный файл под именем Makefile в каталог, где находится ваше расширение. После этого выполните make, чтобы скомпилировать, а затем make install, чтобы установить ваш модуль. По умолчанию расширение компилируется и устанавливается для той инсталляции Postgres Pro, которая соответствует экземпляру pg_config, найденному первым при поиске по пути в PATH. Чтобы использовать другую инсталляцию, вы можете задать в PG_CONFIG путь к её экземпляру pg_config либо внутри сборочного файла, либо в командном файле 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. Затем вы сможете выполнить сборку, установив переменную VPATH для make таким образом:
make VPATH=/path/to/extension/source/tree make VPATH=/path/to/extension/source/tree install
Эта процедура поддерживает самые разные расположения каталогов.
Скрипты, перечисленные в переменной REGRESS, используются для регрессионного тестирования модуля, и вызвать их можно командой make installcheck после make install. Для проведения тестирования необходим работающий сервер Postgres Pro. Файлы скриптов, перечисленные в REGRESS, должны размещаться в подкаталоге sql/ каталога расширения. Эти файлы должны иметь расширение .sql, но указывать его в списке REGRESS в сборочном файле не нужно. Для каждого теста также должен создаваться файл с ожидаемым выводом в подкаталоге expected/, с тем же базовым именем и расширением .out. Команда make installcheck выполнит каждый тест в psql и сравнит полученный вывод с ожидаемым. Все выявленные различия будут записаны в файл regression.diffs в формате команды diff -c. Заметьте, что при попытке запустить тест без файла ожидаемого вывода этот тест будет отмечен как «проблемный», поэтому убедитесь, что все такие файлы присутствуют.
Подсказка
Проще всего для этого создать пустые файлы ожидаемого вывода, а затем выполнить тест (при этом, конечно, будут выявлены несоответствия). Изучите полученные файлы результатов, сохранённые в каталоге results/, и, если они соответствуют вашим ожиданиям от теста, скопируйте их в expected/.
39.17. Extension Building Infrastructure
If you are thinking about distributing your Postgres Pro extension modules, setting up a portable build system for them can be fairly difficult. Therefore the Postgres Pro installation provides a build infrastructure for extensions, called PGXS, so that simple extension modules can be built simply against an already installed server. PGXS is mainly intended for extensions that include C code, although it can be used for pure-SQL extensions too. Note that PGXS is not intended to be a universal build system framework that can be used to build any software interfacing to Postgres Pro; it simply automates common build rules for simple server extension modules. For more complicated packages, you might need to write your own build system.
To use the PGXS infrastructure for your extension, you must write a simple makefile. In the makefile, you need to set some variables and include the global PGXS makefile. Here is an example that builds an extension module named isbn_issn, consisting of a shared library containing some C code, an extension control file, a SQL script, an include file (only needed if other modules might need to access the extension functions without going via SQL), and a documentation text file:
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)
The last three lines should always be the same. Earlier in the file, you assign variables or add custom make rules.
Set one of these three variables to specify what is built:
MODULESlist of shared-library objects to be built from source files with same stem (do not include library suffixes in this list)
MODULE_biga shared library to build from multiple source files (list object files in
OBJS)PROGRAMan executable program to build (list object files in
OBJS)
The following variables can also be set:
EXTENSIONextension name(s); for each name you must provide an
file, which will be installed intoextension.controlprefix/share/extensionMODULEDIRsubdirectory of
into which DATA and DOCS files should be installed (if not set, default isprefix/shareextensionifEXTENSIONis set, orcontribif not)DATArandom files to install into
prefix/share/$MODULEDIRDATA_builtrandom files to install into
, which need to be built firstprefix/share/$MODULEDIRDATA_TSEARCHrandom files to install under
prefix/share/tsearch_dataDOCSrandom files to install under
prefix/doc/$MODULEDIRHEADERSHEADERS_builtFiles to (optionally build and) install under
.prefix/include/server/$MODULEDIR/$MODULE_bigUnlike
DATA_built, files inHEADERS_builtare not removed by thecleantarget; if you want them removed, also add them toEXTRA_CLEANor add your own rules to do it.HEADERS_$MODULEHEADERS_built_$MODULEFiles to install (after building if specified) under
, whereprefix/include/server/$MODULEDIR/$MODULE$MODULEmust be a module name used inMODULESorMODULE_big.Unlike
DATA_built, files inHEADERS_built_$MODULEare not removed by thecleantarget; if you want them removed, also add them toEXTRA_CLEANor add your own rules to do it.It is legal to use both variables for the same module, or any combination, unless you have two module names in the
MODULESlist that differ only by the presence of a prefixbuilt_, which would cause ambiguity. In that (hopefully unlikely) case, you should use only theHEADERS_built_$MODULEvariables.SCRIPTSscript files (not binaries) to install into
prefix/binSCRIPTS_builtscript files (not binaries) to install into
, which need to be built firstprefix/binREGRESSlist of regression test cases (without suffix), see below
REGRESS_OPTSadditional switches to pass to pg_regress
NO_INSTALLCHECKdon't define an
installchecktarget, useful e.g., if tests require special configuration, or don't use pg_regressEXTRA_CLEANextra files to remove in
make cleanPG_CPPFLAGSwill be prepended to
CPPFLAGSPG_CFLAGSwill be appended to
CFLAGSPG_CXXFLAGSwill be appended to
CXXFLAGSPG_LDFLAGSwill be prepended to
LDFLAGSPG_LIBSwill be added to
PROGRAMlink lineSHLIB_LINKwill be added to
MODULE_biglink linePG_CONFIGpath to pg_config program for the Postgres Pro installation to build against (typically just
pg_configto use the first one in yourPATH)
Put this makefile as Makefile in the directory which holds your extension. Then you can do make to compile, and then make install to install your module. By default, the extension is compiled and installed for the Postgres Pro installation that corresponds to the first pg_config program found in your PATH. You can use a different installation by setting PG_CONFIG to point to its pg_config program, either within the makefile or on the make command line.
You can also run make in a directory outside the source tree of your extension, if you want to keep the build directory separate. This procedure is also called a VPATH build. Here's how:
mkdir build_dir cd build_dir make -f /path/to/extension/source/tree/Makefile make -f /path/to/extension/source/tree/Makefile install
Alternatively, you can set up a directory for a VPATH build in a similar way to how it is done for the core code. One way to do this is using the core script config/prep_buildtree. Once this has been done you can build by setting the make variable VPATH like this:
make VPATH=/path/to/extension/source/tree make VPATH=/path/to/extension/source/tree install
This procedure can work with a greater variety of directory layouts.
The scripts listed in the REGRESS variable are used for regression testing of your module, which can be invoked by make installcheck after doing make install. For this to work you must have a running Postgres Pro server. The script files listed in REGRESS must appear in a subdirectory named sql/ in your extension's directory. These files must have extension .sql, which must not be included in the REGRESS list in the makefile. For each test there should also be a file containing the expected output in a subdirectory named expected/, with the same stem and extension .out. make installcheck executes each test script with psql, and compares the resulting output to the matching expected file. Any differences will be written to the file regression.diffs in diff -c format. Note that trying to run a test that is missing its expected file will be reported as “trouble”, so make sure you have all expected files.
Tip
The easiest way to create the expected files is to create empty files, then do a test run (which will of course report differences). Inspect the actual result files found in the results/ directory, then copy them to expected/ if they match what you expect from the test.