2015-04-26 10:33:14 -04:00
|
|
|
# contrib/hstore_plperl/Makefile
|
|
|
|
|
|
|
|
MODULE_big = hstore_plperl
|
2019-11-05 14:41:07 -08:00
|
|
|
OBJS = \
|
|
|
|
$(WIN32RES) \
|
|
|
|
hstore_plperl.o
|
2015-05-03 09:10:47 -04:00
|
|
|
PGFILEDESC = "hstore_plperl - hstore transform for plperl"
|
2015-04-26 10:33:14 -04:00
|
|
|
|
2015-05-01 22:16:58 -04:00
|
|
|
|
2015-04-26 10:33:14 -04:00
|
|
|
EXTENSION = hstore_plperl hstore_plperlu
|
|
|
|
DATA = hstore_plperl--1.0.sql hstore_plperlu--1.0.sql
|
|
|
|
|
2015-04-26 16:09:22 -04:00
|
|
|
REGRESS = hstore_plperl hstore_plperlu create_transform
|
2015-04-26 10:33:14 -04:00
|
|
|
EXTRA_INSTALL = contrib/hstore
|
|
|
|
|
|
|
|
ifdef USE_PGXS
|
2018-09-16 18:46:45 +01:00
|
|
|
PG_CPPFLAGS = -I$(includedir_server)/extension
|
2015-04-26 10:33:14 -04:00
|
|
|
PG_CONFIG = pg_config
|
|
|
|
PGXS := $(shell $(PG_CONFIG) --pgxs)
|
|
|
|
include $(PGXS)
|
|
|
|
else
|
2018-09-16 18:46:45 +01:00
|
|
|
PG_CPPFLAGS = -I$(top_srcdir)/src/pl/plperl -I$(top_srcdir)/contrib
|
2015-04-26 10:33:14 -04:00
|
|
|
subdir = contrib/hstore_plperl
|
|
|
|
top_builddir = ../..
|
|
|
|
include $(top_builddir)/src/Makefile.global
|
|
|
|
include $(top_srcdir)/contrib/contrib-global.mk
|
|
|
|
endif
|
2015-05-02 08:03:47 -04:00
|
|
|
|
2016-10-04 17:49:07 -04:00
|
|
|
# We must link libperl explicitly
|
2015-05-02 08:03:47 -04:00
|
|
|
ifeq ($(PORTNAME), win32)
|
2015-05-03 09:10:47 -04:00
|
|
|
# these settings are the same as for plperl
|
2015-05-02 08:03:47 -04:00
|
|
|
override CPPFLAGS += -DPLPERL_HAVE_UID_GID -Wno-comment
|
2016-10-04 17:49:07 -04:00
|
|
|
# ... 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 16:26:05 -04:00
|
|
|
SHLIB_LINK_INTERNAL += $(sort $(wildcard ../../src/pl/plperl/libperl*.a))
|
2016-10-04 17:49:07 -04:00
|
|
|
else
|
|
|
|
rpathdir = $(perl_archlibexp)/CORE
|
|
|
|
SHLIB_LINK += $(perl_embed_ldflags)
|
2015-05-02 08:03:47 -04:00
|
|
|
endif
|
2015-07-18 10:09:04 -04:00
|
|
|
|
Still further rethinking of build changes for macOS Mojave.
To avoid the sorts of problems complained of by Jakob Egger, it'd be
best if configure didn't emit any references to the sysroot path at all.
In the case of PL/Tcl, we can do that just by keeping our hands off the
TCL_INCLUDE_SPEC string altogether. In the case of PL/Perl, we need to
substitute -iwithsysroot for -I in the compile commands, which is easily
handled if we change to using a configure output variable that includes
the switch not only the directory name. Since PL/Tcl and PL/Python
already do it like that, this seems like good consistency cleanup anyway.
Hence, this replaces the advice given to Perl-related extensions in commit
5e2217131; instead of writing "-I$(perl_archlibexp)/CORE", they should
just write "$(perl_includespec)". (The old way continues to work, but not
on recent macOS.)
It's still the case that configure needs to be aware of the sysroot
path internally, but that's cleaner than what we had before.
As before, back-patch to all supported versions.
Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us
2018-10-18 14:55:23 -04:00
|
|
|
# As with plperl we need to include the perl_includespec directory last.
|
|
|
|
override CPPFLAGS := $(CPPFLAGS) $(perl_embed_ccflags) $(perl_includespec)
|