2018-04-03 15:47:18 +02:00
|
|
|
# contrib/jsonb_plperl/Makefile
|
|
|
|
|
|
|
|
|
|
MODULE_big = jsonb_plperl
|
|
|
|
|
OBJS = jsonb_plperl.o $(WIN32RES)
|
|
|
|
|
PGFILEDESC = "jsonb_plperl - jsonb transform for plperl"
|
|
|
|
|
|
|
|
|
|
PG_CPPFLAGS = -I$(top_srcdir)/src/pl/plperl
|
|
|
|
|
|
|
|
|
|
EXTENSION = jsonb_plperlu jsonb_plperl
|
|
|
|
|
DATA = jsonb_plperlu--1.0.sql jsonb_plperl--1.0.sql
|
|
|
|
|
|
|
|
|
|
REGRESS = jsonb_plperl jsonb_plperlu
|
|
|
|
|
|
Fix platform and Perl-version dependencies in new jsonb_plperl code.
Testing SvTYPE() directly is more fraught with problems than one might
think, because depending on context Perl might be storing a scalar value
in one of several forms, eg both numeric and string values. This resulted
in Perl-version-dependent buildfarm test failures. Instead use the SvTYPE
test only to distinguish non-scalar cases (AV, HV, NULL). Disambiguate
scalars by testing SvIOK, SvNOK, then SvPOK. This creates a preference
order for how we will resolve cases where the value is available in more
than one form, which seems fine to me.
Furthermore, because we're now dealing directly with a "double" value
in the SvNOK case, we can get rid of an inadequate and unportable
string-comparison test for infinities, and use isinf() instead.
(We do need some additional #include and "-lm" infrastructure to use
that in a contrib module, per prior experiences.)
In passing, prevent the regression test results from depending on DROP
CASCADE order; I've not seen that malfunction, but it's trouble waiting
to happen.
Discussion: https://postgr.es/m/E1f3MMJ-0006bf-B0@gemulon.postgresql.org
2018-04-04 17:28:33 +02:00
|
|
|
SHLIB_LINK += $(filter -lm, $(LIBS))
|
|
|
|
|
|
2018-04-03 15:47:18 +02:00
|
|
|
ifdef USE_PGXS
|
|
|
|
|
PG_CONFIG = pg_config
|
|
|
|
|
PGXS := $(shell $(PG_CONFIG) --pgxs)
|
|
|
|
|
include $(PGXS)
|
|
|
|
|
else
|
|
|
|
|
subdir = contrib/jsonb_plperl
|
|
|
|
|
top_builddir = ../..
|
|
|
|
|
include $(top_builddir)/src/Makefile.global
|
|
|
|
|
include $(top_srcdir)/contrib/contrib-global.mk
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# We must link libperl explicitly
|
|
|
|
|
ifeq ($(PORTNAME), win32)
|
|
|
|
|
# these settings are the same as for plperl
|
|
|
|
|
override CPPFLAGS += -DPLPERL_HAVE_UID_GID -Wno-comment
|
|
|
|
|
# ... see silliness in plperl Makefile ...
|
Prevent accidental linking of system-supplied copies of libpq.so etc.
We were being careless in some places about the order of -L switches in
link command lines, such that -L switches referring to external directories
could come before those referring to directories within the build tree.
This made it possible to accidentally link a system-supplied library, for
example /usr/lib/libpq.so, in place of the one built in the build tree.
Hilarity ensued, the more so the older the system-supplied library is.
To fix, break LDFLAGS into two parts, a sub-variable LDFLAGS_INTERNAL
and the main LDFLAGS variable, both of which are "recursively expanded"
so that they can be incrementally adjusted by different makefiles.
Establish a policy that -L switches for directories in the build tree
must always be added to LDFLAGS_INTERNAL, while -L switches for external
directories must always be added to LDFLAGS. This is sufficient to
ensure a safe search order. For simplicity, we typically also put -l
switches for the respective libraries into those same variables.
(Traditional make usage would have us put -l switches into LIBS, but
cleaning that up is a project for another day, as there's no clear
need for it.)
This turns out to also require separating SHLIB_LINK into two variables,
SHLIB_LINK and SHLIB_LINK_INTERNAL, with a similar rule about which
switches go into which variable. And likewise for PG_LIBS.
Although this change might appear to affect external users of pgxs.mk,
I think it doesn't; they shouldn't have any need to touch the _INTERNAL
variables.
In passing, tweak src/common/Makefile so that the value of CPPFLAGS
recorded in pg_config lacks "-DFRONTEND" and the recorded value of
LDFLAGS lacks "-L../../../src/common". Both of those things are
mistakes, apparently introduced during prior code rearrangements,
as old versions of pg_config don't print them. In general we don't
want anything that's specific to the src/common subdirectory to
appear in those outputs.
This is certainly a bug fix, but in view of the lack of field
complaints, I'm unsure whether it's worth the risk of back-patching.
In any case it seems wise to see what the buildfarm makes of it first.
Discussion: https://postgr.es/m/25214.1522604295@sss.pgh.pa.us
2018-04-03 22:26:05 +02:00
|
|
|
SHLIB_LINK_INTERNAL += $(sort $(wildcard ../../src/pl/plperl/libperl*.a))
|
2018-04-03 15:47:18 +02:00
|
|
|
else
|
|
|
|
|
rpathdir = $(perl_archlibexp)/CORE
|
|
|
|
|
SHLIB_LINK += $(perl_embed_ldflags)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# As with plperl we need to make sure that the CORE directory is included
|
|
|
|
|
# last, probably because it sometimes contains some header files with names
|
|
|
|
|
# that clash with some of ours, or with some that we include, notably on
|
|
|
|
|
# Windows.
|
2018-09-25 19:23:29 +02:00
|
|
|
override CPPFLAGS := $(CPPFLAGS) $(perl_embed_ccflags) -I$(perl_includedir)/CORE
|
