如果你正在考虑发布你的LightDB扩展模块,为它们建立一个可移植的构建系统实在是相当困难。因此LightDB安装为扩展提供了一种被称为PGXS构建基础设施,因此简单的扩展模块能够在一个已经安装的服务器上简单地编译。PGXS主要是为了包括 C 代码的扩展而设计,不过它也能用于纯 SQL 的扩展。注意PGXS并不想成为一种用于构建任何与LightDB交互的软件的通用构建系统框架。它只是简单地把简单服务器扩展模块的公共构建规则自动化。对于更复杂的包,你可能需要编写你自己的构建系统。
要把PGXS基础设施用于你的扩展,你必须编写一个简单的 makefile。在这个 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 = lt_config PGXS := $(shell $(PG_CONFIG) --pgxs) include $(PGXS)
最后三行应该总是相同的。在这个文件的前面部分,你要对变量赋值或者增加自定义的make规则。
设置这三个变量之一来指定要构建什么:
MODULES
要从源文件构建的具有相同词干的共享库对象的列表(不要在这个列表中包括库后缀)
MODULE_big
一个要从多个源文件中构建的共享库(在OBJS
中列出对象文件)
PROGRAM
一个要构建的可执行程序(在OBJS
中列出对象文件)
还可以设置下列变量:
EXTENSION
扩展名称;你必须为每一个名称提供一个
文件,它将被安装到extension
.control
中
prefix
/share/extension
MODULEDIR
subdirectory of
的子目录,DATA 和 DOCS 文件会被安装到其中(如果没有设置,设置了prefix
/shareEXTENSION
时默认为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
or 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_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
要在其中构建的LightDB安装的lt_config程序的路径(通常只用在你的PATH
中的第一个lt_config
)
把这个 makefile 作为Makefile
放在保存你扩展的目录中。然后你可以执行make
进行编译,并且接着make install
来安装你的模块。默认情况下,该模块会为在你的PATH
中找到的第一个lt_config
程序所对应的LightDB安装编译和安装。你可以通过在 makefile 中或者make
命令行中设置PG_CONFIG
指向另一个lt_config
程序来使用一个不同的安装。
如果你想保持编译目录独立,你也可以在你的扩展所属的源代码树之外的目录中运行
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 install
之后用make installcheck
调用。要让这能够工作,你必须已经有一个运行着的LightDB服务器。列举在REGRESS
中的脚本文件必须在你扩展目录的名为sql/
的子目录中出现。这些文件必须带有扩展.sql
,但扩展不能被包括在 makefile 的REGRESS
列表中。对每一个测试还应该在名为expected/
的子目录中有一个包含预期输出的文件,它具有和脚本文件相同的词干并带有扩展.out
。make installcheck
会用ltsql执行每一个测试脚本,并且将得到结果输出与相应的预期输出比较。任何区别都将以diff -c
格式写入到文件regression.diffs
中。注意尝试运行一个不带预期文件的测试将被报告为“故障”,因此确保你拥有所有的预期文件。
ISOLATION
变量中列出的脚本用于测试强调与模块并发会话的行为,可以在make install
之后通过make installcheck
调用。
要实现这个工作,你必须有一个正在运行的LightDB服务器。
ISOLATION
中列出的脚本文件必须显示在扩展名目录中名为 specs/
的子目录中。
这些文件必须具备扩展名.spec
,并且不得包含在 makefile 中的ISOLATION
列表中。
对于每个测试,在名为expected/
的子目录中还应该有一个包含预期输出的文件,并且具有相同的词干和扩展名 .out
。
make installcheck
执行每个测试脚本,并将结果输出与匹配的预期文件进行比较。
任何差异都将以diff -c
的格式写入到output_iso/regression.diffs
文件中。
请注意,尝试运行缺少其预期文件的测试将会报告“trouble”,因此请确保你具有全部的预期文件。
创建预期文件最简单的方法是创建空文件,然后做一次测试运行(这当然将报告区别)。
检查在results/
目录中找到的实际结果文件 (对于 REGRESS
中的测试), 或output_iso/results/
目录(对于ISOLATION
)中的测试,如果它们符合你的预期则把它们复制到expected/
中。