2000-06-27 02:32:06 +02:00
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
|
#
|
|
|
|
|
# Makefile for src/bin/psql
|
|
|
|
|
#
|
2023-01-02 21:00:37 +01:00
|
|
|
# Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2001-02-18 19:34:02 +01:00
|
|
|
# Portions Copyright (c) 1994, Regents of the University of California
|
2000-06-27 02:32:06 +02:00
|
|
|
#
|
2010-09-20 22:08:53 +02:00
|
|
|
# src/bin/psql/Makefile
|
2000-06-27 02:32:06 +02:00
|
|
|
#
|
|
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
|
|
2004-10-05 21:30:25 +02:00
|
|
|
PGFILEDESC = "psql - the PostgreSQL interactive terminal"
|
|
|
|
|
PGAPPICON=win32
|
2010-05-12 13:33:10 +02:00
|
|
|
|
2000-06-27 02:32:06 +02:00
|
|
|
subdir = src/bin/psql
|
|
|
|
|
top_builddir = ../../..
|
2000-08-31 18:12:35 +02:00
|
|
|
include $(top_builddir)/src/Makefile.global
|
2000-06-27 02:32:06 +02:00
|
|
|
|
2020-01-02 21:02:21 +01:00
|
|
|
# make this available to TAP test scripts
|
|
|
|
|
export with_readline
|
|
|
|
|
|
2000-06-27 02:32:06 +02:00
|
|
|
REFDOCDIR= $(top_srcdir)/doc/src/sgml/ref
|
|
|
|
|
|
2016-03-24 20:55:44 +01:00
|
|
|
override CPPFLAGS := -I. -I$(srcdir) -I$(libpq_srcdir) $(CPPFLAGS)
|
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
|
|
|
LDFLAGS_INTERNAL += -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport)
|
2000-06-27 02:32:06 +02:00
|
|
|
|
2019-11-05 23:41:07 +01:00
|
|
|
OBJS = \
|
|
|
|
|
$(WIN32RES) \
|
|
|
|
|
command.o \
|
|
|
|
|
common.o \
|
|
|
|
|
copy.o \
|
|
|
|
|
crosstabview.o \
|
|
|
|
|
describe.o \
|
|
|
|
|
help.o \
|
|
|
|
|
input.o \
|
|
|
|
|
large_obj.o \
|
|
|
|
|
mainloop.o \
|
|
|
|
|
prompt.o \
|
|
|
|
|
psqlscanslash.o \
|
|
|
|
|
sql_help.o \
|
|
|
|
|
startup.o \
|
|
|
|
|
stringutils.o \
|
|
|
|
|
tab-complete.o \
|
|
|
|
|
variables.o
|
2004-02-19 20:40:09 +01:00
|
|
|
|
2000-06-27 02:32:06 +02:00
|
|
|
|
2010-11-12 21:15:16 +01:00
|
|
|
all: psql
|
2000-06-27 02:32:06 +02:00
|
|
|
|
2016-03-24 20:55:44 +01:00
|
|
|
psql: $(OBJS) | submake-libpq submake-libpgport submake-libpgfeutils
|
Fix broken link-command-line ordering for libpgfeutils.
In the frontend Makefiles that pull in libpgfeutils, we'd generally
done it like this:
LDFLAGS += -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport)
That method is badly broken, as seen in bug #14742 from Chris Ruprecht.
The -L flag for src/fe_utils ends up being placed after whatever random
-L flags are in LDFLAGS already. That puts us at risk of pulling in
libpgfeutils.a from some previous installation rather than the freshly
built one in src/fe_utils. Also, the lack of an "override" is hazardous
if someone tries to specify some LDFLAGS on the make command line.
The correct way to do it is like this:
override LDFLAGS := -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport) $(LDFLAGS)
so that libpgfeutils, along with libpq, libpgport, and libpgcommon, are
guaranteed to be pulled in from the build tree and not from any referenced
system directory, because their -L flags will appear first.
In some places we'd been even lazier and done it like this:
LDFLAGS += -L$(top_builddir)/src/fe_utils -lpgfeutils -lpq
which is subtly wrong in an additional way: on platforms where we can't
restrict the symbols exported by libpq.so, it allows libpgfeutils to
latch onto libpgport and libpgcommon symbols from libpq.so, rather than
directly from those static libraries as intended. This carries hazards
like those explained in the comments for the libpq_pgport macro.
In addition to fixing the broken libpgfeutils usages, I tried to
standardize on using $(libpq_pgport) like so:
override LDFLAGS := $(libpq_pgport) $(LDFLAGS)
even where libpgfeutils is not in the picture. This makes no difference
right now but will hopefully discourage future mistakes of the same ilk.
And it's more like the way we handle CPPFLAGS in libpq-using Makefiles.
In passing, just for consistency, make pgbench include PTHREAD_LIBS the
same way everyplace else does, ie just after LIBS rather than in some
random place in the command line. This might have practical effect if
there are -L switches in that macro on some platform.
It looks to me like the MSVC build scripts are not affected by this
error, but someone more familiar with them than I might want to double
check.
Back-patch to 9.6 where libpgfeutils was introduced. In 9.6, the hazard
this error creates is that a reinstallation might link to the prior
installation's copy of libpgfeutils.a and thereby fail to absorb a
minor-version bug fix.
Discussion: https://postgr.es/m/20170714125106.9231.13772@wrigleys.postgresql.org
2017-07-14 18:26:53 +02:00
|
|
|
$(CC) $(CFLAGS) $(OBJS) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X)
|
2000-06-27 02:32:06 +02:00
|
|
|
|
2009-08-28 22:26:19 +02:00
|
|
|
help.o: sql_help.h
|
2000-06-27 02:32:06 +02:00
|
|
|
|
Fix make rules that generate multiple output files.
For years, our makefiles have correctly observed that "there is no correct
way to write a rule that generates two files". However, what we did is to
provide empty rules that "generate" the secondary output files from the
primary one, and that's not right either. Depending on the details of
the creating process, the primary file might end up timestamped later than
one or more secondary files, causing subsequent make runs to consider the
secondary file(s) out of date. That's harmless in a plain build, since
make will just re-execute the empty rule and nothing happens. But it's
fatal in a VPATH build, since make will expect the secondary file to be
rebuilt in the build directory. This would manifest as "file not found"
failures during VPATH builds from tarballs, if we were ever unlucky enough
to ship a tarball with apparently out-of-date secondary files. (It's not
clear whether that has ever actually happened, but it definitely could.)
To ensure that secondary output files have timestamps >= their primary's,
change our makefile convention to be that we provide a "touch $@" action
not an empty rule. Also, make sure that this rule actually gets invoked
during a distprep run, else the hazard remains.
It's been like this a long time, so back-patch to all supported branches.
In HEAD, I skipped the changes in src/backend/catalog/Makefile, because
those rules are due to get replaced soon in the bootstrap data format
patch, and there seems no need to create a merge issue for that patch.
If for some reason we fail to land that patch in v11, we'll need to
back-fill the changes in that one makefile from v10.
Discussion: https://postgr.es/m/18556.1521668179@sss.pgh.pa.us
2018-03-23 18:45:37 +01:00
|
|
|
# See notes in src/backend/parser/Makefile about the following two rules
|
|
|
|
|
sql_help.c: sql_help.h
|
|
|
|
|
touch $@
|
|
|
|
|
|
2009-08-28 22:26:19 +02:00
|
|
|
sql_help.h: create_help.pl $(wildcard $(REFDOCDIR)/*.sgml)
|
2022-07-18 20:57:31 +02:00
|
|
|
$(PERL) $< --docdir $(REFDOCDIR) --basename $*
|
2000-06-27 02:32:06 +02:00
|
|
|
|
Split psql's lexer into two separate .l files for SQL and backslash cases.
This gets us to a point where psqlscan.l can be used by other frontend
programs for the same purpose psql uses it for, ie to detect when it's
collected a complete SQL command from input that is divided across
line boundaries. Moreover, other programs can supply their own lexers
for backslash commands of their own choosing. A follow-on patch will
use this in pgbench.
The end result here is roughly the same as in Kyotaro Horiguchi's
0001-Make-SQL-parser-part-of-psqlscan-independent-from-ps.patch, although
the details of the method for switching between lexers are quite different.
Basically, in this patch we share the entire PsqlScanState, YY_BUFFER_STATE
stack, *and* yyscan_t between different lexers. The only thing we need
to do to switch to a different lexer is to make sure the start_state is
valid for the new lexer. This works because flex doesn't keep any other
persistent state that depends on the specific lexing tables generated for
a particular .l file. (We are assuming that both lexers are built with
the same flex version, or at least versions that are compatible with
respect to the contents of yyscan_t; but that doesn't seem likely to
be a big problem in practice, considering how slowly flex changes.)
Aside from being more efficient than Horiguchi-san's original solution,
this avoids possible corner-case changes in semantics: the original code
was capable of popping the input buffer stack while still staying in
backslash-related parsing states. I'm not sure that that equates to any
useful user-visible behaviors, but I'm not sure it doesn't either, so
I'm loath to assume that we only need to consider the topmost buffer when
parsing a backslash command.
I've attempted to update the MSVC build scripts for the added .l file,
but will rely on the buildfarm to see if I missed anything.
Kyotaro Horiguchi and Tom Lane
2016-03-19 05:24:55 +01:00
|
|
|
psqlscanslash.c: FLEXFLAGS = -Cfe -p -p
|
2016-03-25 01:28:47 +01:00
|
|
|
psqlscanslash.c: FLEX_NO_BACKUP=yes
|
2017-02-19 19:04:30 +01:00
|
|
|
psqlscanslash.c: FLEX_FIX_WARNING=yes
|
Convert psql's flex lexer to be re-entrant, and make it compile standalone.
Change psqlscan.l to specify '%option reentrant', adjust internal APIs
to match, and get rid of its internal static variables. While this is
good cleanup in an abstract sense, the reason to do it right now is that
it seems the only practical way to support use of separate flex lexers
with common PsqlScanState infrastructure. If we build two non-reentrant
lexers then we are going to have problems with dangling buffer pointers
in whichever lexer isn't active when we transition from one buffer to
another, as well as curious side-effects if we try to share any code
between the files. (Horiguchi-san had a different solution to that in his
pending patch, but I find it ugly and probably broken for corner cases.)
Depending on which version of flex you're using, this may result in getting
a "warning: unused variable 'yyg'" warning from psqlscan, similar to the
one you'd have seen for a long time in backend/parser/scan.l. I put a
local -Wno-error into CFLAGS for the file, for the convenience of those
who compile with -Werror.
Also, stop compiling psqlscan as part of mainloop.c, and make it a
standalone build target instead. This is a lot cleaner than before, though
it doesn't really change much in practice as of this commit. (I'm not sure
whether the MSVC build scripts will need some help with this part, but the
buildfarm will soon tell us.)
2016-03-19 02:21:52 +01:00
|
|
|
|
2000-06-27 02:32:06 +02:00
|
|
|
install: all installdirs
|
2005-12-09 22:19:36 +01:00
|
|
|
$(INSTALL_PROGRAM) psql$(X) '$(DESTDIR)$(bindir)/psql$(X)'
|
|
|
|
|
$(INSTALL_DATA) $(srcdir)/psqlrc.sample '$(DESTDIR)$(datadir)/psqlrc.sample'
|
2000-06-27 02:32:06 +02:00
|
|
|
|
|
|
|
|
installdirs:
|
2014-01-18 05:08:22 +01:00
|
|
|
$(MKDIR_P) '$(DESTDIR)$(bindir)' '$(DESTDIR)$(datadir)'
|
2000-06-27 02:32:06 +02:00
|
|
|
|
|
|
|
|
uninstall:
|
2005-12-09 22:19:36 +01:00
|
|
|
rm -f '$(DESTDIR)$(bindir)/psql$(X)' '$(DESTDIR)$(datadir)/psqlrc.sample'
|
2000-06-27 02:32:06 +02:00
|
|
|
|
|
|
|
|
clean distclean:
|
2016-03-24 20:55:44 +01:00
|
|
|
rm -f psql$(X) $(OBJS) lex.backup
|
2020-01-02 21:02:21 +01:00
|
|
|
rm -rf tmp_check
|
2016-03-25 01:28:47 +01:00
|
|
|
rm -f sql_help.h sql_help.c psqlscanslash.c
|
2020-01-02 21:02:21 +01:00
|
|
|
|
|
|
|
|
check:
|
|
|
|
|
$(prove_check)
|
|
|
|
|
|
|
|
|
|
installcheck:
|
|
|
|
|
$(prove_installcheck)
|
