|
|
|
|
# Makefile for PL/Perl
|
|
|
|
|
# src/pl/plperl/GNUmakefile
|
|
|
|
|
|
|
|
|
|
subdir = src/pl/plperl
|
|
|
|
|
top_builddir = ../../..
|
|
|
|
|
include $(top_builddir)/src/Makefile.global
|
|
|
|
|
|
|
|
|
|
ifeq ($(PORTNAME), win32)
|
|
|
|
|
override CPPFLAGS += -DPLPERL_HAVE_UID_GID
|
|
|
|
|
# Perl on win32 contains /* within comment all over the header file,
|
|
|
|
|
# so disable this warning.
|
|
|
|
|
override CPPFLAGS += -Wno-comment
|
|
|
|
|
endif
|
|
|
|
|
|
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
7 years ago
|
|
|
# Note: we need to include the perl_includespec directory last,
|
PL/Perl portability fix: absorb relevant -D switches from Perl.
The Perl documentation is very clear that stuff calling libperl should
be built with the compiler switches shown by Perl's $Config{ccflags}.
We'd been ignoring that up to now, and mostly getting away with it,
but recent Perl versions contain ABI compatibility cross-checks that
fail on some builds because of this omission. In particular the
sizeof(PerlInterpreter) can come out different due to some fields being
added or removed; which means we have a live ABI hazard that we'd better
fix rather than continuing to sweep it under the rug.
However, it still seems like a bad idea to just absorb $Config{ccflags}
verbatim. In some environments Perl was built with a different compiler
that doesn't even use the same switch syntax. -D switch syntax is pretty
universal though, and absorbing Perl's -D switches really ought to be
enough to fix the problem.
Furthermore, Perl likes to inject stuff like -D_LARGEFILE_SOURCE and
-D_FILE_OFFSET_BITS=64 into $Config{ccflags}, which affect libc ABIs on
platforms where they're relevant. Adopting those seems dangerous too.
It's unclear whether a build wherein Perl and Postgres have different ideas
of sizeof(off_t) etc would work, or whether anyone would care about making
it work. But it's dead certain that having different stdio ABIs in
core Postgres and PL/Perl will not work; we've seen that movie before.
Therefore, let's also ignore -D switches for symbols beginning with
underscore. The symbols that we actually need to import should be the ones
mentioned in perl.h's PL_bincompat_options stanza, and none of those start
with underscore, so this seems likely to work. (If it turns out not to
work everywhere, we could consider intersecting the symbols mentioned in
PL_bincompat_options with the -D switches. But that will be much more
complicated, so let's try this way first.)
This will need to be back-patched, but first let's see what the
buildfarm makes of it.
Ashutosh Sharma, some adjustments by me
Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
8 years ago
|
|
|
# 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.
|
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
7 years ago
|
|
|
override CPPFLAGS := -I. -I$(srcdir) $(CPPFLAGS) $(perl_embed_ccflags) $(perl_includespec)
|
|
|
|
|
|
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
7 years ago
|
|
|
# this is often, but not always, the same directory named by perl_includespec
|
|
|
|
|
rpathdir = $(perl_archlibexp)/CORE
|
|
|
|
|
|
|
|
|
|
PGFILEDESC = "PL/Perl - procedural language"
|
|
|
|
|
|
|
|
|
|
NAME = plperl
|
|
|
|
|
|
|
|
|
|
OBJS = plperl.o SPI.o Util.o $(WIN32RES)
|
|
|
|
|
|
|
|
|
|
DATA = plperl.control plperl--1.0.sql \
|
|
|
|
|
plperlu.control plperlu--1.0.sql
|
|
|
|
|
|
|
|
|
|
PERLCHUNKS = plc_perlboot.pl plc_trusted.pl
|
|
|
|
|
|
|
|
|
|
# Perl on win32 ships with import libraries only for Microsoft Visual C++,
|
|
|
|
|
# which are not compatible with mingw gcc. Therefore we need to build a
|
|
|
|
|
# new import library to link with.
|
|
|
|
|
ifeq ($(PORTNAME), win32)
|
|
|
|
|
|
|
|
|
|
perlwithver := $(subst -l,,$(filter -l%, $(perl_embed_ldflags)))
|
|
|
|
|
PERLDLL := $(dir $(subst ',,$(PERL)))$(perlwithver).dll
|
|
|
|
|
# we no longer want to include the original -l spec in SHLIB_LINK
|
|
|
|
|
override perl_embed_ldflags :=
|
|
|
|
|
|
|
|
|
|
OBJS += lib$(perlwithver).a
|
|
|
|
|
|
|
|
|
|
lib$(perlwithver).a: $(perlwithver).def
|
|
|
|
|
dlltool --dllname $(perlwithver).dll --def $(perlwithver).def --output-lib lib$(perlwithver).a
|
|
|
|
|
|
|
|
|
|
$(perlwithver).def: $(PERLDLL)
|
|
|
|
|
gendef - $^ > $@
|
|
|
|
|
|
|
|
|
|
endif # win32
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SHLIB_LINK = $(perl_embed_ldflags)
|
|
|
|
|
|
|
|
|
|
# see https://www.postgresql.org/message-id/flat/8c4fcb72-2574-ff7c-4c25-1f032d4a2a57%40enterprisedb.com
|
|
|
|
|
ifeq ($(PORTNAME), cygwin)
|
|
|
|
|
SHLIB_LINK += -Wl,--export-all-symbols
|
|
|
|
|
endif
|
|
|
|
|
|
Invent "trusted" extensions, and remove the pg_pltemplate catalog.
This patch creates a new extension property, "trusted". An extension
that's marked that way in its control file can be installed by a
non-superuser who has the CREATE privilege on the current database,
even if the extension contains objects that normally would have to be
created by a superuser. The objects within the extension will (by
default) be owned by the bootstrap superuser, but the extension itself
will be owned by the calling user. This allows replicating the old
behavior around trusted procedural languages, without all the
special-case logic in CREATE LANGUAGE. We have, however, chosen to
loosen the rules slightly: formerly, only a database owner could take
advantage of the special case that allowed installation of a trusted
language, but now anyone who has CREATE privilege can do so.
Having done that, we can delete the pg_pltemplate catalog, moving the
knowledge it contained into the extension script files for the various
PLs. This ends up being no change at all for the in-core PLs, but it is
a large step forward for external PLs: they can now have the same ease
of installation as core PLs do. The old "trusted PL" behavior was only
available to PLs that had entries in pg_pltemplate, but now any
extension can be marked trusted if appropriate.
This also removes one of the stumbling blocks for our Python 2 -> 3
migration, since the association of "plpythonu" with Python 2 is no
longer hard-wired into pg_pltemplate's initial contents. Exactly where
we go from here on that front remains to be settled, but one problem
is fixed.
Patch by me, reviewed by Peter Eisentraut, Stephen Frost, and others.
Discussion: https://postgr.es/m/5889.1566415762@sss.pgh.pa.us
6 years ago
|
|
|
REGRESS_OPTS = --dbname=$(PL_TESTDB)
|
|
|
|
|
REGRESS = plperl_setup plperl plperl_lc plperl_trigger plperl_shared \
|
|
|
|
|
plperl_elog plperl_util plperl_init plperlu plperl_array \
|
|
|
|
|
plperl_call plperl_transaction
|
|
|
|
|
# if Perl can support two interpreters in one backend,
|
|
|
|
|
# test plperl-and-plperlu cases
|
|
|
|
|
ifneq ($(PERL),)
|
|
|
|
|
ifeq ($(shell $(PERL) -V:usemultiplicity), usemultiplicity='define';)
|
|
|
|
|
REGRESS += plperl_plperlu
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# where to find xsubpp for building XS.
|
|
|
|
|
XSUBPPDIR = $(shell $(PERL) -e 'use List::Util qw(first); print first { -r "$$_/ExtUtils/xsubpp" } @INC')
|
|
|
|
|
|
|
|
|
|
include $(top_srcdir)/src/Makefile.shlib
|
|
|
|
|
|
|
|
|
|
plperl.o: perlchunks.h plperl_opmask.h
|
|
|
|
|
|
|
|
|
|
plperl_opmask.h: plperl_opmask.pl
|
|
|
|
|
@if [ x"$(perl_privlibexp)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
|
|
|
|
|
$(PERL) $< $@
|
|
|
|
|
|
|
|
|
|
perlchunks.h: $(PERLCHUNKS)
|
|
|
|
|
@if [ x"$(perl_privlibexp)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
|
|
|
|
|
$(PERL) $(srcdir)/text2macro.pl --strip='^(\#.*|\s*)$$' $^ > $@
|
|
|
|
|
|
|
|
|
|
all: all-lib
|
|
|
|
|
|
|
|
|
|
%.c: %.xs
|
|
|
|
|
@if [ x"$(perl_privlibexp)" = x"" ]; then echo "configure switch --with-perl was not specified."; exit 1; fi
|
|
|
|
|
# xsubpp -output option is required for coverage+vpath, but requires Perl 5.9.3
|
|
|
|
|
ifeq ($(enable_coverage)$(vpath_build),yesyes)
|
|
|
|
|
$(PERL) $(XSUBPPDIR)/ExtUtils/xsubpp -typemap $(perl_privlibexp)/ExtUtils/typemap -output $@ $<
|
|
|
|
|
else
|
|
|
|
|
$(PERL) $(XSUBPPDIR)/ExtUtils/xsubpp -typemap $(perl_privlibexp)/ExtUtils/typemap $< >$@
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
install: all install-lib install-data
|
|
|
|
|
|
|
|
|
|
installdirs: installdirs-lib
|
|
|
|
|
$(MKDIR_P) '$(DESTDIR)$(datadir)/extension' '$(DESTDIR)$(includedir_server)'
|
|
|
|
|
|
|
|
|
|
uninstall: uninstall-lib uninstall-data
|
|
|
|
|
|
|
|
|
|
install-data: installdirs
|
|
|
|
|
$(INSTALL_DATA) $(addprefix $(srcdir)/, $(DATA)) '$(DESTDIR)$(datadir)/extension/'
|
|
|
|
|
$(INSTALL_DATA) $(srcdir)/plperl.h $(srcdir)/plperl_system.h $(srcdir)/ppport.h '$(DESTDIR)$(includedir_server)'
|
|
|
|
|
|
|
|
|
|
uninstall-data:
|
|
|
|
|
rm -f $(addprefix '$(DESTDIR)$(datadir)/extension'/, $(notdir $(DATA)))
|
|
|
|
|
rm -f $(addprefix '$(DESTDIR)$(includedir_server)'/, plperl.h plperl_system.h ppport.h)
|
|
|
|
|
|
|
|
|
|
.PHONY: install-data uninstall-data
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
check: submake
|
|
|
|
|
$(pg_regress_check) $(REGRESS_OPTS) $(REGRESS)
|
|
|
|
|
|
|
|
|
|
installcheck: submake
|
|
|
|
|
$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS)
|
|
|
|
|
|
|
|
|
|
.PHONY: submake
|
|
|
|
|
submake:
|
|
|
|
|
$(MAKE) -C $(top_builddir)/src/test/regress pg_regress$(X)
|
|
|
|
|
|
Remove distprep
A PostgreSQL release tarball contains a number of prebuilt files, in
particular files produced by bison, flex, perl, and well as html and
man documentation. We have done this consistent with established
practice at the time to not require these tools for building from a
tarball. Some of these tools were hard to get, or get the right
version of, from time to time, and shipping the prebuilt output was a
convenience to users.
Now this has at least two problems:
One, we have to make the build system(s) work in two modes: Building
from a git checkout and building from a tarball. This is pretty
complicated, but it works so far for autoconf/make. It does not
currently work for meson; you can currently only build with meson from
a git checkout. Making meson builds work from a tarball seems very
difficult or impossible. One particular problem is that since meson
requires a separate build directory, we cannot make the build update
files like gram.h in the source tree. So if you were to build from a
tarball and update gram.y, you will have a gram.h in the source tree
and one in the build tree, but the way things work is that the
compiler will always use the one in the source tree. So you cannot,
for example, make any gram.y changes when building from a tarball.
This seems impossible to fix in a non-horrible way.
Second, there is increased interest nowadays in precisely tracking the
origin of software. We can reasonably track contributions into the
git tree, and users can reasonably track the path from a tarball to
packages and downloads and installs. But what happens between the git
tree and the tarball is obscure and in some cases non-reproducible.
The solution for both of these issues is to get rid of the step that
adds prebuilt files to the tarball. The tarball now only contains
what is in the git tree (*). Getting the additional build
dependencies is no longer a problem nowadays, and the complications to
keep these dual build modes working are significant. And of course we
want to get the meson build system working universally.
This commit removes the make distprep target altogether. The make
dist target continues to do its job, it just doesn't call distprep
anymore.
(*) - The tarball also contains the INSTALL file that is built at make
dist time, but not by distprep. This is unchanged for now.
The make maintainer-clean target, whose job it is to remove the
prebuilt files in addition to what make distclean does, is now just an
alias to make distprep. (In practice, it is probably obsolete given
that git clean is available.)
The following programs are now hard build requirements in configure
(they were already required by meson.build):
- bison
- flex
- perl
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://www.postgresql.org/message-id/flat/e07408d9-e5f2-d9fd-5672-f53354e9305e@eisentraut.org
2 years ago
|
|
|
clean distclean: clean-lib
|
|
|
|
|
rm -f SPI.c Util.c $(OBJS) perlchunks.h plperl_opmask.h
|
|
|
|
|
rm -rf $(pg_regress_clean_files)
|
|
|
|
|
ifeq ($(PORTNAME), win32)
|
|
|
|
|
rm -f $(perlwithver).def
|
|
|
|
|
endif
|
