1996-07-09 08:22:35 +02:00
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
|
#
|
2000-07-06 23:33:45 +02:00
|
|
|
# Makefile for the postgres backend
|
1996-07-09 08:22:35 +02:00
|
|
|
#
|
2023-01-02 21:00:37 +01:00
|
|
|
# Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2007-08-21 03:11:32 +02:00
|
|
|
# Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
#
|
2010-09-20 22:08:53 +02:00
|
|
|
# src/backend/Makefile
|
1996-07-09 08:22:35 +02:00
|
|
|
#
|
|
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
|
|
2006-06-18 17:38:37 +02:00
|
|
|
PGFILEDESC = "PostgreSQL Server"
|
2023-06-12 16:40:38 +02:00
|
|
|
PGAPPICON=win32
|
2010-05-12 13:33:10 +02:00
|
|
|
|
2000-07-06 23:33:45 +02:00
|
|
|
subdir = src/backend
|
|
|
|
|
top_builddir = ../..
|
2000-08-31 18:12:35 +02:00
|
|
|
include $(top_builddir)/src/Makefile.global
|
1996-07-09 08:22:35 +02:00
|
|
|
|
Redesign archive modules
A new callback named startup_cb, called shortly after a module is
loaded, is added. This makes possible the initialization of any
additional state data required by a module. This initial state data can
be saved in a ArchiveModuleState, that is now passed down to all the
callbacks that can be defined in a module. With this design, it is
possible to have a per-module state, aimed at opening the door to the
support of more than one archive module.
The initialization of the callbacks is changed so as
_PG_archive_module_init() does not anymore give in input a
ArchiveModuleCallbacks that a module has to fill in with callback
definitions. Instead, a module now needs to return a const
ArchiveModuleCallbacks.
All the structure and callback definitions of archive modules are moved
into their own header, named archive_module.h, from pgarch.h.
Command-based archiving follows the same line, with a new set of files
named shell_archive.{c,h}.
There are a few more items that are under discussion to improve the
design of archive modules, like the fact that basic_archive calls
sigsetjmp() by itself to define its own error handling flow. These will
be adjusted later, the changes done here cover already a good portion
of what has been discussed.
Any modules created for v15 will need to be adjusted to this new
design.
Author: Nathan Bossart
Reviewed-by: Andres Freund
Discussion: https://postgr.es/m/20230130194810.6fztfgbn32e7qarj@awork3.anarazel.de
2023-02-17 06:26:42 +01:00
|
|
|
SUBDIRS = access archive backup bootstrap catalog parser commands executor \
|
2022-08-10 20:03:23 +02:00
|
|
|
foreign lib libpq \
|
Faster partition pruning
Add a new module backend/partitioning/partprune.c, implementing a more
sophisticated algorithm for partition pruning. The new module uses each
partition's "boundinfo" for pruning instead of constraint exclusion,
based on an idea proposed by Robert Haas of a "pruning program": a list
of steps generated from the query quals which are run iteratively to
obtain a list of partitions that must be scanned in order to satisfy
those quals.
At present, this targets planner-time partition pruning, but there exist
further patches to apply partition pruning at execution time as well.
This commit also moves some definitions from include/catalog/partition.h
to a new file include/partitioning/partbounds.h, in an attempt to
rationalize partitioning related code.
Authors: Amit Langote, David Rowley, Dilip Kumar
Reviewers: Robert Haas, Kyotaro Horiguchi, Ashutosh Bapat, Jesper Pedersen.
Discussion: https://postgr.es/m/098b9c71-1915-1a2a-8d52-1a7a50ce79e8@lab.ntt.co.jp
2018-04-06 21:23:04 +02:00
|
|
|
main nodes optimizer partitioning port postmaster \
|
|
|
|
|
regex replication rewrite \
|
2018-03-22 03:28:28 +01:00
|
|
|
statistics storage tcop tsearch utils $(top_builddir)/src/timezone \
|
2020-12-28 03:37:42 +01:00
|
|
|
jit
|
2004-04-30 18:08:01 +02:00
|
|
|
|
2008-02-25 18:55:42 +01:00
|
|
|
include $(srcdir)/common.mk
|
2005-07-28 06:31:30 +02:00
|
|
|
|
2010-01-21 00:12:03 +01:00
|
|
|
# As of 1/2010:
|
|
|
|
|
# The probes.o file is necessary for dtrace support on Solaris, and on recent
|
|
|
|
|
# versions of systemtap. (Older systemtap releases just produce an empty
|
Refer to OS X as "macOS", except for the port name which is still "darwin".
We weren't terribly consistent about whether to call Apple's OS "OS X"
or "Mac OS X", and the former is probably confusing to people who aren't
Apple users. Now that Apple has rebranded it "macOS", follow their lead
to establish a consistent naming pattern. Also, avoid the use of the
ancient project name "Darwin", except as the port code name which does not
seem desirable to change. (In short, this patch touches documentation and
comments, but no actual code.)
I didn't touch contrib/start-scripts/osx/, either. I suspect those are
obsolete and due for a rewrite, anyway.
I dithered about whether to apply this edit to old release notes, but
those were responsible for quite a lot of the inconsistencies, so I ended
up changing them too. Anyway, Apple's being ahistorical about this,
so why shouldn't we be?
2016-09-25 21:40:57 +02:00
|
|
|
# file, but that's okay.) However, macOS's dtrace doesn't use it and doesn't
|
|
|
|
|
# even recognize the -G option. So, build probes.o except on macOS.
|
2010-01-21 00:12:03 +01:00
|
|
|
# This might need adjustment as other platforms add dtrace support.
|
|
|
|
|
ifneq ($(PORTNAME), darwin)
|
2006-07-24 18:32:45 +02:00
|
|
|
ifeq ($(enable_dtrace), yes)
|
|
|
|
|
LOCALOBJS += utils/probes.o
|
|
|
|
|
endif
|
2009-09-05 23:14:04 +02:00
|
|
|
endif
|
2006-07-24 18:32:45 +02:00
|
|
|
|
2019-11-05 23:41:07 +01:00
|
|
|
OBJS = \
|
|
|
|
|
$(LOCALOBJS) \
|
|
|
|
|
$(SUBDIROBJS) \
|
|
|
|
|
$(top_builddir)/src/common/libpgcommon_srv.a \
|
|
|
|
|
$(top_builddir)/src/port/libpgport_srv.a
|
2005-07-28 06:31:30 +02:00
|
|
|
|
2013-02-22 02:46:17 +01:00
|
|
|
# We put libpgport and libpgcommon into OBJS, so remove it from LIBS; also add
|
2017-08-21 06:22:18 +02:00
|
|
|
# libldap and ICU
|
|
|
|
|
LIBS := $(filter-out -lpgport -lpgcommon, $(LIBS)) $(LDAP_LIBS_BE) $(ICU_LIBS)
|
2000-05-29 07:45:56 +02:00
|
|
|
|
2005-11-28 23:06:39 +01:00
|
|
|
# The backend doesn't need everything that's in LIBS, however
|
Server-side gzip compression.
pg_basebackup's --compression option now lets you write either
"client-gzip" or "server-gzip" instead of just "gzip" to specify
where the compression should be performed. If you write simply
"gzip" it's taken to mean "client-gzip" unless you also use
--target, in which case it is interpreted to mean "server-gzip",
because that's the only thing that makes any sense in that case.
To make this work, the BASE_BACKUP command now takes new
COMPRESSION and COMPRESSION_LEVEL options.
At present, pg_basebackup cannot decompress .gz files, so
server-side compression will cause a failure if (1) -Ft is not
used or (2) -R is used or (3) -D- is used without --no-manifest.
Along the way, I removed the information message added by commit
5c649fe153367cdab278738ee4aebbfd158e0546 which occurred if you
specified no compression level and told you that the default level
had been used instead. That seemed like more output than most
people would want.
Also along the way, this adds a check to the server for
unrecognized base backup options. This repairs a bug introduced
by commit 0ba281cb4bf9f5f65529dfa4c8282abb734dd454.
This commit also adds some new test cases for pg_verifybackup.
They take a server-side backup with and without compression, and
then extract the backup if we have the OS facilities available
to do so, and then run pg_verifybackup on the extracted
directory. That is a good test of the functionality added by
this commit and also improves test coverage for the backup target
patch (commit 3500ccc39b0dadd1068a03938e4b8ff562587ccc) and for
pg_verifybackup itself.
Patch by me, with a bug fix by Jeevan Ladhe. The patch set of which
this is a part has also had review and/or testing from Tushar Ahuja,
Suraj Kharage, Dipesh Pandit, and Mark Dilger.
Discussion: http://postgr.es/m/CA+Tgmoa-ST7fMLsVJduOB7Eub=2WjfpHS+QxHVEpUoinf4bOSg@mail.gmail.com
2022-01-24 21:13:18 +01:00
|
|
|
LIBS := $(filter-out -lreadline -ledit -ltermcap -lncurses -lcurses, $(LIBS))
|
2005-11-28 23:06:39 +01:00
|
|
|
|
2015-11-17 12:46:17 +01:00
|
|
|
ifeq ($(with_systemd),yes)
|
|
|
|
|
LIBS += -lsystemd
|
|
|
|
|
endif
|
|
|
|
|
|
2022-12-07 03:55:28 +01:00
|
|
|
override LDFLAGS := $(LDFLAGS) $(LDFLAGS_EX) $(LDFLAGS_EX_BE)
|
|
|
|
|
|
2000-07-06 23:33:45 +02:00
|
|
|
##########################################################################
|
1999-01-17 07:20:06 +01:00
|
|
|
|
2018-05-03 23:54:18 +02:00
|
|
|
all: submake-libpgport submake-catalog-headers submake-utils-headers postgres $(POSTGRES_IMP)
|
1998-01-04 20:13:04 +01:00
|
|
|
|
2003-03-21 18:18:34 +01:00
|
|
|
ifneq ($(PORTNAME), cygwin)
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01:00
|
|
|
ifneq ($(PORTNAME), win32)
|
2005-10-27 22:45:29 +02:00
|
|
|
ifneq ($(PORTNAME), aix)
|
2000-05-29 07:45:56 +02:00
|
|
|
|
2000-07-13 18:07:14 +02:00
|
|
|
postgres: $(OBJS)
|
2022-12-07 03:55:28 +01:00
|
|
|
$(CC) $(CFLAGS) $(call expand_subsys,$^) $(LDFLAGS) $(LIBS) -o $@
|
2000-05-29 07:45:56 +02:00
|
|
|
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01:00
|
|
|
endif
|
|
|
|
|
endif
|
2005-10-27 22:45:29 +02:00
|
|
|
endif
|
2000-05-29 07:45:56 +02:00
|
|
|
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01:00
|
|
|
ifeq ($(PORTNAME), cygwin)
|
2005-10-27 22:45:29 +02:00
|
|
|
|
2014-02-11 18:10:52 +01:00
|
|
|
postgres: $(OBJS)
|
2022-12-07 03:55:28 +01:00
|
|
|
$(CC) $(CFLAGS) $(call expand_subsys,$^) $(LDFLAGS) -Wl,--stack,$(WIN32_STACK_RLIMIT) -Wl,--export-all-symbols -Wl,--out-implib=libpostgres.a $(LIBS) -o $@
|
2002-09-05 20:28:46 +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
|
|
|
# libpostgres.a is actually built in the preceding rule, but we need this to
|
|
|
|
|
# ensure it's newer than postgres; see notes in src/backend/parser/Makefile
|
|
|
|
|
libpostgres.a: postgres
|
|
|
|
|
touch $@
|
1999-01-17 07:20:06 +01:00
|
|
|
|
2003-03-21 18:18:34 +01:00
|
|
|
endif # cygwin
|
2000-07-06 23:33:45 +02:00
|
|
|
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01:00
|
|
|
ifeq ($(PORTNAME), win32)
|
2018-04-30 19:20:13 +02:00
|
|
|
LIBS += -lsecur32
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01:00
|
|
|
|
2014-02-11 18:56:20 +01:00
|
|
|
postgres: $(OBJS) $(WIN32RES)
|
2022-12-07 03:55:28 +01:00
|
|
|
$(CC) $(CFLAGS) $(call expand_subsys,$(OBJS)) $(WIN32RES) $(LDFLAGS) -Wl,--stack=$(WIN32_STACK_RLIMIT) -Wl,--export-all-symbols -Wl,--out-implib=libpostgres.a $(LIBS) -o $@$(X)
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01: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
|
|
|
# libpostgres.a is actually built in the preceding rule, but we need this to
|
|
|
|
|
# ensure it's newer than postgres; see notes in src/backend/parser/Makefile
|
|
|
|
|
libpostgres.a: postgres
|
|
|
|
|
touch $@
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01:00
|
|
|
|
|
|
|
|
endif # win32
|
|
|
|
|
|
2002-10-09 18:21:54 +02:00
|
|
|
ifeq ($(PORTNAME), aix)
|
|
|
|
|
|
|
|
|
|
postgres: $(POSTGRES_IMP)
|
2022-12-07 03:55:28 +01:00
|
|
|
$(CC) $(CFLAGS) $(call expand_subsys,$(OBJS)) $(LDFLAGS) -Wl,-bE:$(top_builddir)/src/backend/$(POSTGRES_IMP) $(LIBS) -Wl,-brtllib -o $@
|
2002-10-09 18:21:54 +02:00
|
|
|
|
2022-12-02 04:03:26 +01:00
|
|
|
# Linking to a single .o with -r is a lot faster than building a .a or passing
|
|
|
|
|
# all objects to MKLDEXPORT.
|
|
|
|
|
#
|
|
|
|
|
# It looks alluring to use $(CC) -r instead of ld -r, but that doesn't
|
|
|
|
|
# trivially work with gcc, due to gcc specific static libraries linked in with
|
|
|
|
|
# -r.
|
2002-10-09 18:21:54 +02:00
|
|
|
$(POSTGRES_IMP): $(OBJS)
|
2022-12-02 04:03:26 +01:00
|
|
|
ld -r -o SUBSYS.o $(call expand_subsys,$^)
|
2022-08-07 20:34:42 +02:00
|
|
|
$(MKLDEXPORT) SUBSYS.o . > $@
|
2002-10-09 18:21:54 +02:00
|
|
|
@rm -f SUBSYS.o
|
|
|
|
|
|
|
|
|
|
endif # aix
|
1997-03-12 21:44:57 +01:00
|
|
|
|
2010-11-12 21:15:16 +01:00
|
|
|
$(top_builddir)/src/port/libpgport_srv.a: | submake-libpgport
|
2010-01-05 02:20:35 +01:00
|
|
|
|
2000-07-06 23:33:45 +02:00
|
|
|
|
|
|
|
|
# The following targets are specified in make commands that appear in
|
|
|
|
|
# the make files in our subdirectories. Note that it's important we
|
|
|
|
|
# match the dependencies shown in the subdirectory makefiles!
|
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
|
|
|
# Also, in cases where a subdirectory makefile generates two files in
|
|
|
|
|
# what's really one step, such as bison producing both gram.h and gram.c,
|
|
|
|
|
# we must request making the one that is shown as the secondary (dependent)
|
|
|
|
|
# output, else the timestamp on it might be wrong. By project convention,
|
|
|
|
|
# the .h file is the dependent one for bison output, so we need only request
|
|
|
|
|
# that; but in other cases, request both for safety.
|
1996-11-23 10:51:57 +01:00
|
|
|
|
2009-08-28 22:26:19 +02:00
|
|
|
parser/gram.h: parser/gram.y
|
2008-08-29 15:02:33 +02:00
|
|
|
$(MAKE) -C parser gram.h
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2015-09-11 19:58:28 +02:00
|
|
|
storage/lmgr/lwlocknames.h: storage/lmgr/generate-lwlocknames.pl storage/lmgr/lwlocknames.txt
|
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
|
|
|
$(MAKE) -C storage/lmgr lwlocknames.h lwlocknames.c
|
2015-09-11 19:58:28 +02:00
|
|
|
|
Generate automatically code and documentation related to wait events
The documentation and the code is generated automatically from a new
file called wait_event_names.txt, formatted in sections dedicated to
each wait event class (Timeout, Lock, IO, etc.) with three tab-separated
fields:
- C symbol in enums
- Format in the system views
- Description in the docs
Using this approach has several advantages, as we have proved to be
rather bad in maintaining this area of the tree across the years:
- The order of each item in the documentation and the code, which should
be alphabetical, has become incorrect multiple times, and the script
generating the code and documentation has a few rules to enforce that,
making the maintenance a no-brainer.
- Some wait events were added to the code, but not documented, so this
cannot be missed now.
- The order of the tables for each wait event class is enforced in the
documentation (the input .txt file does so as well for clarity, though
this is not mandatory).
- Less code, shaving 1.2k lines from the tree, with 1/3 of the savings
coming from the code, the rest from the documentation.
The wait event types "Lock" and "LWLock" still have their own code path
for their code, hence only the documentation is created for them. These
classes are listed with a special marker called WAIT_EVENT_DOCONLY in
the input file.
Adding a new wait event now requires only an update of
wait_event_names.txt, with "Lock" and "LWLock" treated as exceptions.
This commit has been tested with configure/Makefile, the CI and VPATH
build. clean, distclean and maintainer-clean were working fine.
Author: Bertrand Drouvot, Michael Paquier
Discussion: https://postgr.es/m/77a86b3a-c4a8-5f5d-69b9-d70bbf2e9b98@gmail.com
2023-07-05 03:53:11 +02:00
|
|
|
utils/activity/wait_event_types.h: utils/activity/generate-wait_event_types.pl utils/activity/wait_event_names.txt
|
Add system view pg_wait_events
This new view, wrapped around a SRF, shows some information known about
wait events, as of:
- Name.
- Type (Activity, I/O, Extension, etc.).
- Description.
All the information retrieved comes from wait_event_names.txt, and the
description is the same as the documentation with filters applied to
remove any XML markups. This view is useful when joined with
pg_stat_activity to get the description of a wait event reported.
Custom wait events for extensions are included in the view.
Original idea by Yves Colin.
Author: Bertrand Drouvot
Reviewed-by: Kyotaro Horiguchi, Masahiro Ikeda, Tom Lane, Michael
Paquier
Discussion: https://postgr.es/m/0e2ae164-dc89-03c3-cf7f-de86378053ac@gmail.com
2023-08-20 08:35:02 +02:00
|
|
|
$(MAKE) -C utils/activity wait_event_types.h pgstat_wait_event.c wait_event_funcs_data.c
|
Generate automatically code and documentation related to wait events
The documentation and the code is generated automatically from a new
file called wait_event_names.txt, formatted in sections dedicated to
each wait event class (Timeout, Lock, IO, etc.) with three tab-separated
fields:
- C symbol in enums
- Format in the system views
- Description in the docs
Using this approach has several advantages, as we have proved to be
rather bad in maintaining this area of the tree across the years:
- The order of each item in the documentation and the code, which should
be alphabetical, has become incorrect multiple times, and the script
generating the code and documentation has a few rules to enforce that,
making the maintenance a no-brainer.
- Some wait events were added to the code, but not documented, so this
cannot be missed now.
- The order of the tables for each wait event class is enforced in the
documentation (the input .txt file does so as well for clarity, though
this is not mandatory).
- Less code, shaving 1.2k lines from the tree, with 1/3 of the savings
coming from the code, the rest from the documentation.
The wait event types "Lock" and "LWLock" still have their own code path
for their code, hence only the documentation is created for them. These
classes are listed with a special marker called WAIT_EVENT_DOCONLY in
the input file.
Adding a new wait event now requires only an update of
wait_event_names.txt, with "Lock" and "LWLock" treated as exceptions.
This commit has been tested with configure/Makefile, the CI and VPATH
build. clean, distclean and maintainer-clean were working fine.
Author: Bertrand Drouvot, Michael Paquier
Discussion: https://postgr.es/m/77a86b3a-c4a8-5f5d-69b9-d70bbf2e9b98@gmail.com
2023-07-05 03:53:11 +02:00
|
|
|
|
2016-07-01 21:08:55 +02:00
|
|
|
# run this unconditionally to avoid needing to know its dependencies here:
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
submake-catalog-headers:
|
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
2023-11-06 14:51:52 +01:00
|
|
|
$(MAKE) -C catalog generated-header-symlinks
|
2016-07-01 21:08:55 +02:00
|
|
|
|
Automatically generate node support functions
Add a script to automatically generate the node support functions
(copy, equal, out, and read, as well as the node tags enum) from the
struct definitions.
For each of the four node support files, it creates two include files,
e.g., copyfuncs.funcs.c and copyfuncs.switch.c, to include in the main
file. All the scaffolding of the main file stays in place.
I have tried to mostly make the coverage of the output match what is
currently there. For example, one could now do out/read coverage of
utility statement nodes, but I have manually excluded those for now.
The reason is mainly that it's easier to diff the before and after,
and adding a bunch of stuff like this might require a separate
analysis and review.
Subtyping (TidScan -> Scan) is supported.
For the hard cases, you can just write a manual function and exclude
generating one. For the not so hard cases, there is a way of
annotating struct fields to get special behaviors. For example,
pg_node_attr(equal_ignore) has the field ignored in equal functions.
(In this patch, I have only ifdef'ed out the code to could be removed,
mainly so that it won't constantly have merge conflicts. It will be
deleted in a separate patch. All the code comments that are worth
keeping from those sections have already been moved to the header
files where the structs are defined.)
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce%40enterprisedb.com
2022-07-09 08:52:19 +02:00
|
|
|
# run this unconditionally to avoid needing to know its dependencies here:
|
|
|
|
|
submake-nodes-headers:
|
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
2023-11-06 14:51:52 +01:00
|
|
|
$(MAKE) -C nodes generated-header-symlinks
|
Automatically generate node support functions
Add a script to automatically generate the node support functions
(copy, equal, out, and read, as well as the node tags enum) from the
struct definitions.
For each of the four node support files, it creates two include files,
e.g., copyfuncs.funcs.c and copyfuncs.switch.c, to include in the main
file. All the scaffolding of the main file stays in place.
I have tried to mostly make the coverage of the output match what is
currently there. For example, one could now do out/read coverage of
utility statement nodes, but I have manually excluded those for now.
The reason is mainly that it's easier to diff the before and after,
and adding a bunch of stuff like this might require a separate
analysis and review.
Subtyping (TidScan -> Scan) is supported.
For the hard cases, you can just write a manual function and exclude
generating one. For the not so hard cases, there is a way of
annotating struct fields to get special behaviors. For example,
pg_node_attr(equal_ignore) has the field ignored in equal functions.
(In this patch, I have only ifdef'ed out the code to could be removed,
mainly so that it won't constantly have merge conflicts. It will be
deleted in a separate patch. All the code comments that are worth
keeping from those sections have already been moved to the header
files where the structs are defined.)
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce%40enterprisedb.com
2022-07-09 08:52:19 +02:00
|
|
|
|
2018-05-03 23:54:18 +02:00
|
|
|
# run this unconditionally to avoid needing to know its dependencies here:
|
|
|
|
|
submake-utils-headers:
|
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
2023-11-06 14:51:52 +01:00
|
|
|
$(MAKE) -C utils generated-header-symlinks
|
2018-05-03 23:54:18 +02:00
|
|
|
|
Automatically generate node support functions
Add a script to automatically generate the node support functions
(copy, equal, out, and read, as well as the node tags enum) from the
struct definitions.
For each of the four node support files, it creates two include files,
e.g., copyfuncs.funcs.c and copyfuncs.switch.c, to include in the main
file. All the scaffolding of the main file stays in place.
I have tried to mostly make the coverage of the output match what is
currently there. For example, one could now do out/read coverage of
utility statement nodes, but I have manually excluded those for now.
The reason is mainly that it's easier to diff the before and after,
and adding a bunch of stuff like this might require a separate
analysis and review.
Subtyping (TidScan -> Scan) is supported.
For the hard cases, you can just write a manual function and exclude
generating one. For the not so hard cases, there is a way of
annotating struct fields to get special behaviors. For example,
pg_node_attr(equal_ignore) has the field ignored in equal functions.
(In this patch, I have only ifdef'ed out the code to could be removed,
mainly so that it won't constantly have merge conflicts. It will be
deleted in a separate patch. All the code comments that are worth
keeping from those sections have already been moved to the header
files where the structs are defined.)
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce%40enterprisedb.com
2022-07-09 08:52:19 +02:00
|
|
|
.PHONY: submake-catalog-headers submake-nodes-headers submake-utils-headers
|
2016-07-01 21:08:55 +02:00
|
|
|
|
2000-07-06 23:33:45 +02:00
|
|
|
# Make symlinks for these headers in the include directory. That way
|
|
|
|
|
# we can cut down on the -I options. Also, a symlink is automatically
|
|
|
|
|
# up to date when we update the base file.
|
1999-11-14 18:12:42 +01:00
|
|
|
|
2016-07-01 21:08:55 +02:00
|
|
|
.PHONY: generated-headers
|
|
|
|
|
|
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
2023-11-06 14:51:52 +01:00
|
|
|
generated-headers: $(top_builddir)/src/include/storage/lwlocknames.h $(top_builddir)/src/include/utils/wait_event_types.h submake-catalog-headers submake-nodes-headers submake-utils-headers parser/gram.h
|
2000-05-29 07:45:56 +02:00
|
|
|
|
2015-09-11 19:58:28 +02:00
|
|
|
$(top_builddir)/src/include/storage/lwlocknames.h: storage/lmgr/lwlocknames.h
|
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
2023-11-06 14:51:52 +01:00
|
|
|
rm -f '$@'
|
|
|
|
|
$(LN_S) ../../backend/$< '$@'
|
2015-09-11 19:58:28 +02:00
|
|
|
|
Generate automatically code and documentation related to wait events
The documentation and the code is generated automatically from a new
file called wait_event_names.txt, formatted in sections dedicated to
each wait event class (Timeout, Lock, IO, etc.) with three tab-separated
fields:
- C symbol in enums
- Format in the system views
- Description in the docs
Using this approach has several advantages, as we have proved to be
rather bad in maintaining this area of the tree across the years:
- The order of each item in the documentation and the code, which should
be alphabetical, has become incorrect multiple times, and the script
generating the code and documentation has a few rules to enforce that,
making the maintenance a no-brainer.
- Some wait events were added to the code, but not documented, so this
cannot be missed now.
- The order of the tables for each wait event class is enforced in the
documentation (the input .txt file does so as well for clarity, though
this is not mandatory).
- Less code, shaving 1.2k lines from the tree, with 1/3 of the savings
coming from the code, the rest from the documentation.
The wait event types "Lock" and "LWLock" still have their own code path
for their code, hence only the documentation is created for them. These
classes are listed with a special marker called WAIT_EVENT_DOCONLY in
the input file.
Adding a new wait event now requires only an update of
wait_event_names.txt, with "Lock" and "LWLock" treated as exceptions.
This commit has been tested with configure/Makefile, the CI and VPATH
build. clean, distclean and maintainer-clean were working fine.
Author: Bertrand Drouvot, Michael Paquier
Discussion: https://postgr.es/m/77a86b3a-c4a8-5f5d-69b9-d70bbf2e9b98@gmail.com
2023-07-05 03:53:11 +02:00
|
|
|
$(top_builddir)/src/include/utils/wait_event_types.h: utils/activity/wait_event_types.h
|
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
2023-11-06 14:51:52 +01:00
|
|
|
rm -f '$@'
|
|
|
|
|
$(LN_S) ../../backend/$< '$@'
|
Generate automatically code and documentation related to wait events
The documentation and the code is generated automatically from a new
file called wait_event_names.txt, formatted in sections dedicated to
each wait event class (Timeout, Lock, IO, etc.) with three tab-separated
fields:
- C symbol in enums
- Format in the system views
- Description in the docs
Using this approach has several advantages, as we have proved to be
rather bad in maintaining this area of the tree across the years:
- The order of each item in the documentation and the code, which should
be alphabetical, has become incorrect multiple times, and the script
generating the code and documentation has a few rules to enforce that,
making the maintenance a no-brainer.
- Some wait events were added to the code, but not documented, so this
cannot be missed now.
- The order of the tables for each wait event class is enforced in the
documentation (the input .txt file does so as well for clarity, though
this is not mandatory).
- Less code, shaving 1.2k lines from the tree, with 1/3 of the savings
coming from the code, the rest from the documentation.
The wait event types "Lock" and "LWLock" still have their own code path
for their code, hence only the documentation is created for them. These
classes are listed with a special marker called WAIT_EVENT_DOCONLY in
the input file.
Adding a new wait event now requires only an update of
wait_event_names.txt, with "Lock" and "LWLock" treated as exceptions.
This commit has been tested with configure/Makefile, the CI and VPATH
build. clean, distclean and maintainer-clean were working fine.
Author: Bertrand Drouvot, Michael Paquier
Discussion: https://postgr.es/m/77a86b3a-c4a8-5f5d-69b9-d70bbf2e9b98@gmail.com
2023-07-05 03:53:11 +02:00
|
|
|
|
2015-10-15 19:16:03 +02:00
|
|
|
utils/probes.o: utils/probes.d $(SUBDIROBJS)
|
|
|
|
|
$(DTRACE) $(DTRACEFLAGS) -C -G -s $(call expand_subsys,$^) -o $@
|
2006-07-24 18:32:45 +02:00
|
|
|
|
|
|
|
|
|
2000-07-19 18:30:27 +02:00
|
|
|
##########################################################################
|
|
|
|
|
|
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
2023-11-06 14:51:52 +01:00
|
|
|
# This target is only needed by nls.mk.
|
|
|
|
|
.PHONY: generated-parser-sources
|
|
|
|
|
generated-parser-sources:
|
2008-08-29 15:02:33 +02:00
|
|
|
$(MAKE) -C parser gram.c gram.h scan.c
|
2022-09-04 06:33:31 +02:00
|
|
|
$(MAKE) -C bootstrap bootparse.c bootparse.h bootscanner.c
|
|
|
|
|
$(MAKE) -C replication repl_gram.c repl_gram.h repl_scanner.c syncrep_gram.c syncrep_gram.h syncrep_scanner.c
|
2022-09-09 06:34:09 +02:00
|
|
|
$(MAKE) -C utils/adt jsonpath_gram.c jsonpath_gram.h jsonpath_scan.c
|
2000-07-19 18:30:27 +02:00
|
|
|
$(MAKE) -C utils/misc guc-file.c
|
2002-08-21 22:42:27 +02:00
|
|
|
|
2000-07-19 18:30:27 +02:00
|
|
|
|
2000-07-06 23:33:45 +02:00
|
|
|
##########################################################################
|
|
|
|
|
|
2000-07-08 04:40:27 +02:00
|
|
|
install: all installdirs install-bin
|
2003-03-21 18:18:34 +01:00
|
|
|
ifeq ($(PORTNAME), cygwin)
|
1999-01-17 07:20:06 +01:00
|
|
|
ifeq ($(MAKE_DLL), true)
|
2005-12-09 22:19:36 +01:00
|
|
|
$(INSTALL_DATA) libpostgres.a '$(DESTDIR)$(libdir)/libpostgres.a'
|
1999-01-17 07:20:06 +01:00
|
|
|
endif
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01:00
|
|
|
endif
|
|
|
|
|
ifeq ($(PORTNAME), win32)
|
|
|
|
|
ifeq ($(MAKE_DLL), true)
|
2005-12-09 22:19:36 +01:00
|
|
|
$(INSTALL_DATA) libpostgres.a '$(DESTDIR)$(libdir)/libpostgres.a'
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01:00
|
|
|
endif
|
1999-01-17 07:20:06 +01:00
|
|
|
endif
|
2002-12-14 01:24:35 +01:00
|
|
|
$(MAKE) -C catalog install-data
|
2007-08-21 03:11:32 +02:00
|
|
|
$(MAKE) -C tsearch install-data
|
2018-04-05 05:05:40 +02:00
|
|
|
$(MAKE) -C utils install-data
|
2005-12-09 22:19:36 +01:00
|
|
|
$(INSTALL_DATA) $(srcdir)/libpq/pg_hba.conf.sample '$(DESTDIR)$(datadir)/pg_hba.conf.sample'
|
|
|
|
|
$(INSTALL_DATA) $(srcdir)/libpq/pg_ident.conf.sample '$(DESTDIR)$(datadir)/pg_ident.conf.sample'
|
|
|
|
|
$(INSTALL_DATA) $(srcdir)/utils/misc/postgresql.conf.sample '$(DESTDIR)$(datadir)/postgresql.conf.sample'
|
1996-10-27 10:55:05 +01:00
|
|
|
|
2018-03-28 22:19:08 +02:00
|
|
|
ifeq ($(with_llvm), yes)
|
|
|
|
|
install-bin: install-postgres-bitcode
|
|
|
|
|
|
|
|
|
|
install-postgres-bitcode: $(OBJS) all
|
|
|
|
|
$(call install_llvm_module,postgres,$(call expand_subsys, $(filter-out $(top_builddir)/src/timezone/objfiles.txt, $(SUBDIROBJS))))
|
|
|
|
|
endif
|
|
|
|
|
|
2000-07-19 18:30:27 +02:00
|
|
|
install-bin: postgres $(POSTGRES_IMP) installdirs
|
2005-12-09 22:19:36 +01:00
|
|
|
$(INSTALL_PROGRAM) postgres$(X) '$(DESTDIR)$(bindir)/postgres$(X)'
|
2000-07-08 04:40:27 +02:00
|
|
|
ifeq ($(MAKE_EXPORTS), true)
|
2005-12-09 22:19:36 +01:00
|
|
|
$(INSTALL_DATA) $(POSTGRES_IMP) '$(DESTDIR)$(pkglibdir)/$(POSTGRES_IMP)'
|
2012-10-10 03:04:06 +02:00
|
|
|
$(INSTALL_PROGRAM) $(MKLDEXPORT) '$(DESTDIR)$(pgxsdir)/$(MKLDEXPORT_DIR)/mkldexport.sh'
|
2000-07-08 04:40:27 +02:00
|
|
|
endif
|
|
|
|
|
|
2000-07-19 18:30:27 +02:00
|
|
|
.PHONY: install-bin
|
1996-10-27 10:55:05 +01:00
|
|
|
|
2001-09-16 18:11:11 +02:00
|
|
|
installdirs:
|
2009-08-27 00:24:44 +02:00
|
|
|
$(MKDIR_P) '$(DESTDIR)$(bindir)' '$(DESTDIR)$(datadir)'
|
2003-03-21 18:18:34 +01:00
|
|
|
ifeq ($(PORTNAME), cygwin)
|
2001-09-16 18:11:11 +02:00
|
|
|
ifeq ($(MAKE_DLL), true)
|
2009-08-27 00:24:44 +02:00
|
|
|
$(MKDIR_P) '$(DESTDIR)$(libdir)'
|
2001-09-16 18:11:11 +02:00
|
|
|
endif
|
|
|
|
|
endif
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01:00
|
|
|
ifeq ($(PORTNAME), win32)
|
|
|
|
|
ifeq ($(MAKE_DLL), true)
|
2009-08-27 00:24:44 +02:00
|
|
|
$(MKDIR_P) '$(DESTDIR)$(libdir)'
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01:00
|
|
|
endif
|
|
|
|
|
endif
|
2001-09-16 18:11:11 +02:00
|
|
|
ifeq ($(MAKE_EXPORTS), true)
|
2009-08-27 00:24:44 +02:00
|
|
|
$(MKDIR_P) '$(DESTDIR)$(pkglibdir)'
|
2012-10-10 03:04:06 +02:00
|
|
|
$(MKDIR_P) '$(DESTDIR)$(pgxsdir)/$(MKLDEXPORT_DIR)'
|
2001-09-16 18:11:11 +02:00
|
|
|
endif
|
2002-08-21 22:42:27 +02:00
|
|
|
|
2001-09-16 18:11:11 +02:00
|
|
|
|
2000-07-06 23:33:45 +02:00
|
|
|
##########################################################################
|
|
|
|
|
|
|
|
|
|
uninstall:
|
2023-01-26 11:33:01 +01:00
|
|
|
rm -f '$(DESTDIR)$(bindir)/postgres$(X)'
|
1996-11-23 10:51:57 +01:00
|
|
|
ifeq ($(MAKE_EXPORTS), true)
|
2005-12-09 22:19:36 +01:00
|
|
|
rm -f '$(DESTDIR)$(pkglibdir)/$(POSTGRES_IMP)'
|
2012-10-10 03:04:06 +02:00
|
|
|
rm -f '$(DESTDIR)$(pgxsdir)/$(MKLDEXPORT_DIR)/mkldexport.sh'
|
1996-11-23 10:51:57 +01:00
|
|
|
endif
|
2003-03-21 18:18:34 +01:00
|
|
|
ifeq ($(PORTNAME), cygwin)
|
1999-01-17 07:20:06 +01:00
|
|
|
ifeq ($(MAKE_DLL), true)
|
2005-12-09 22:19:36 +01:00
|
|
|
rm -f '$(DESTDIR)$(libdir)/libpostgres.a'
|
1999-01-17 07:20:06 +01:00
|
|
|
endif
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01:00
|
|
|
endif
|
|
|
|
|
ifeq ($(PORTNAME), win32)
|
|
|
|
|
ifeq ($(MAKE_DLL), true)
|
2005-12-09 22:19:36 +01:00
|
|
|
rm -f '$(DESTDIR)$(libdir)/libpostgres.a'
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01:00
|
|
|
endif
|
1999-01-17 07:20:06 +01:00
|
|
|
endif
|
2002-12-14 01:24:35 +01:00
|
|
|
$(MAKE) -C catalog uninstall-data
|
2007-08-21 03:11:32 +02:00
|
|
|
$(MAKE) -C tsearch uninstall-data
|
2018-04-05 05:05:40 +02:00
|
|
|
$(MAKE) -C utils uninstall-data
|
2005-12-09 22:19:36 +01:00
|
|
|
rm -f '$(DESTDIR)$(datadir)/pg_hba.conf.sample' \
|
|
|
|
|
'$(DESTDIR)$(datadir)/pg_ident.conf.sample' \
|
2020-12-28 03:37:42 +01:00
|
|
|
'$(DESTDIR)$(datadir)/postgresql.conf.sample'
|
2018-03-28 22:19:08 +02:00
|
|
|
ifeq ($(with_llvm), yes)
|
|
|
|
|
$(call uninstall_llvm_module,postgres)
|
|
|
|
|
endif
|
1999-03-08 00:05:57 +01:00
|
|
|
|
2000-03-08 23:00:19 +01:00
|
|
|
|
2000-07-06 23:33:45 +02:00
|
|
|
##########################################################################
|
2000-03-08 23:00:19 +01:00
|
|
|
|
2000-07-06 23:33:45 +02:00
|
|
|
clean:
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
rm -f $(LOCALOBJS) postgres$(X) $(POSTGRES_IMP)
|
2003-03-21 18:18:34 +01:00
|
|
|
ifeq ($(PORTNAME), cygwin)
|
2014-02-11 18:10:52 +01:00
|
|
|
rm -f postgres.dll libpostgres.a
|
Briefly,
* configure + Makefile changes
* shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent
cygwin bug under cygwin/EXEC_BACKEND case only)
* PATH env var separator differences
* missing win32 rand functions added
* placeholder replacements for sync etc under port.h
To those who are really interested, and there are a few of you: the attached
patch + file will allow the source base to be compiled (and, for some
definition, "run") under MingW, with the following caveats (I wanted to
first properly fix all but the last of these, but y'all won't quit asking
for a patch :-):
* child death: SIGCHLD not yet sent, so as a minimum, you'll need to
put in some sort of delay after StartupDatabase, and handle setting
StartupPID to 0 etc (ie. the stuff the reaper() signal function is supposed
to do)
* dirmod.c: comment out the elog calls
* dfmgr.c: some hackage required to substitute_libpath_macro
* slru/xact.c: comment out the errno checking after the readdir
(fixed by next version of MingW)
Again, this is only if you *really* want to see postgres compile and start,
and is a nice leg-up for working on the other Win32 TODO list items. Just
don't expect too much else from it at this point...
Claudio Natoli
2004-02-02 01:11:31 +01:00
|
|
|
endif
|
|
|
|
|
ifeq ($(PORTNAME), win32)
|
2014-02-11 18:56:20 +01:00
|
|
|
rm -f postgres.dll libpostgres.a $(WIN32RES)
|
2000-07-06 23:33:45 +02:00
|
|
|
endif
|
2000-03-08 23:00:19 +01:00
|
|
|
|
2000-07-06 23:33:45 +02:00
|
|
|
distclean: clean
|
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
2023-11-06 14:51:52 +01:00
|
|
|
# generated by configure
|
2018-09-06 10:07:24 +02:00
|
|
|
rm -f port/tas.s port/pg_sema.c port/pg_shmem.c
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-03-08 23:00:19 +01:00
|
|
|
|
2000-07-06 23:33:45 +02:00
|
|
|
##########################################################################
|
1996-07-09 08:22:35 +02:00
|
|
|
#
|
|
|
|
|
# Support for code development.
|
|
|
|
|
#
|
2010-11-23 21:27:50 +01:00
|
|
|
# Use target "quick" to build "postgres" when you know all the subsystems
|
1996-11-03 10:05:30 +01:00
|
|
|
# are up to date. It saves the time of doing all the submakes.
|
|
|
|
|
.PHONY: quick
|
|
|
|
|
quick: $(OBJS)
|
2022-12-07 03:55:28 +01:00
|
|
|
$(CC) $(CFLAGS) $(call expand_subsys,$^) $(LDFLAGS) $(LIBS) -o postgres
|
