2000-10-08 23:13:27 +02:00
# -*-makefile-*-
2010-09-20 22:08:53 +02:00
# src/Makefile.global.in
2014-04-15 03:49:57 +02:00
# @configure_input@
2000-08-31 18:12:35 +02:00
#------------------------------------------------------------------------------
# All PostgreSQL makefiles include this file and use the variables it sets,
# which in turn are put here by the configure script. There is no need for
# users to edit this file -- if it turns out to be necessary then that's a
# bug.
1997-02-04 09:53:45 +01:00
#
2000-08-31 18:12:35 +02:00
# A makefile that includes this file needs to set the variable `subdir' to
# the relative path from the top to itself and `top_builddir' to the relative
# path from itself to the top before including this file. (The "top" is the
# parent directory of the directory this file is in.)
#------------------------------------------------------------------------------
1997-02-04 09:53:45 +01:00
2000-10-08 23:13:27 +02:00
##########################################################################
#
# Meta configuration
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
standard_targets = all install installdirs uninstall clean distclean coverage check checkprep installcheck init-po update-po
2011-07-03 19:55:02 +02:00
# these targets should recurse even into subdirectories not being built:
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
standard_always_targets = clean distclean
2010-11-12 21:15:16 +01: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
.PHONY : $( standard_targets ) maintainer -clean install -strip html man installcheck -parallel update -unicode
2000-10-08 23:13:27 +02:00
# make `all' the default target
all :
2000-09-08 20:29:28 +02:00
# Delete target files if the command fails after it has
# started to update the file.
.DELETE_ON_ERROR :
2012-11-01 04:33:35 +01:00
# Never delete any intermediate files automatically.
.SECONDARY :
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
maintainer-clean : distclean
2000-07-02 17:21:27 +02:00
# PostgreSQL version number
2002-03-29 18:32:55 +01:00
VERSION = @PACKAGE_VERSION@
2008-12-11 08:34:09 +01:00
MAJORVERSION = @PG_MAJORVERSION@
2015-07-02 23:24:36 +02:00
VERSION_NUM = @PG_VERSION_NUM@
2000-07-02 17:21:27 +02:00
2020-02-28 08:54:49 +01:00
PACKAGE_URL = @PACKAGE_URL@
2015-07-31 02:48:41 +02:00
# Set top_srcdir, srcdir, and VPATH.
i f d e f P G X S
top_srcdir = $( top_builddir)
# If VPATH is set or Makefile is not in current directory we are building
# the extension with VPATH so we set the variable here.
i f d e f V P A T H
srcdir = $( VPATH)
e l s e
i f e q ( $( CURDIR ) , $( dir $ ( firstword $ ( MAKEFILE_LIST ) ) ) )
srcdir = .
VPATH =
e l s e
srcdir = $( dir $( firstword $( MAKEFILE_LIST) ) )
VPATH = $( srcdir)
e n d i f
e n d i f
e l s e # not PGXS
2002-03-29 18:32:55 +01:00
vpath_build = @vpath_build@
2015-04-23 14:59:52 +02:00
abs_top_builddir = @abs_top_builddir@
2000-10-20 23:04:27 +02:00
abs_top_srcdir = @abs_top_srcdir@
2000-07-09 15:14:19 +02:00
2002-03-29 18:32:55 +01:00
i f n e q ( $( vpath_build ) , y e s )
2000-10-20 23:04:27 +02:00
top_srcdir = $( top_builddir)
2000-06-27 02:32:06 +02:00
srcdir = .
2002-03-29 18:32:55 +01:00
e l s e # vpath_build = yes
2000-10-20 23:04:27 +02:00
top_srcdir = $( abs_top_srcdir)
2000-06-27 02:32:06 +02:00
srcdir = $( top_srcdir) /$( subdir)
VPATH = $( srcdir)
2000-10-20 23:04:27 +02:00
e n d i f
2014-12-04 23:02:02 +01:00
e n d i f # not PGXS
1997-02-04 09:53:45 +01:00
2000-10-08 23:13:27 +02:00
##########################################################################
1997-02-04 09:53:45 +01:00
#
2000-10-08 23:13:27 +02:00
# Installation directories
2004-05-22 02:34:51 +02:00
#
# These are set by the equivalent --xxxdir configure options. We
# append "postgresql" to some of them, if the string does not already
# contain "pgsql" or "postgres", in order to avoid directory clutter.
2005-09-27 19:39:35 +02:00
#
# In a PGXS build, we cannot use the values inserted into Makefile.global
# by configure, since the installation tree may have been relocated.
# Instead get the path values from pg_config.
i f n d e f P G X S
2008-02-17 17:36:43 +01:00
# Note that prefix, exec_prefix, and datarootdir aren't defined in a PGXS build;
2005-09-27 19:39:35 +02:00
# makefiles may only use the derived variables such as bindir.
1997-02-04 09:53:45 +01:00
2000-10-08 23:13:27 +02:00
prefix := @prefix@
exec_prefix := @exec_prefix@
2008-02-17 17:36:43 +01:00
datarootdir := @datarootdir@
1998-10-30 05:54:06 +01:00
2000-10-08 23:13:27 +02:00
bindir := @bindir@
2000-03-08 02:58:46 +01:00
2000-10-08 23:13:27 +02:00
datadir := @datadir@
2004-05-22 02:34:51 +02:00
i f e q "$(findstring pgsql, $(datadir))" ""
i f e q "$(findstring postgres, $(datadir))" ""
override datadir : = $( datadir ) /postgresql
e n d i f
e n d i f
2000-10-08 23:13:27 +02:00
sysconfdir := @sysconfdir@
2004-05-22 02:34:51 +02:00
i f e q "$(findstring pgsql, $(sysconfdir))" ""
i f e q "$(findstring postgres, $(sysconfdir))" ""
override sysconfdir : = $( sysconfdir ) /postgresql
e n d i f
e n d i f
2000-10-08 23:13:27 +02:00
libdir := @libdir@
2005-09-27 19:39:35 +02:00
2004-05-22 02:34:51 +02:00
pkglibdir = $( libdir)
i f e q "$(findstring pgsql, $(pkglibdir))" ""
i f e q "$(findstring postgres, $(pkglibdir))" ""
override pkglibdir : = $( pkglibdir ) /postgresql
e n d i f
e n d i f
2000-10-08 23:13:27 +02:00
includedir := @includedir@
2005-09-27 19:39:35 +02:00
2004-05-22 02:34:51 +02:00
pkgincludedir = $( includedir)
i f e q "$(findstring pgsql, $(pkgincludedir))" ""
i f e q "$(findstring postgres, $(pkgincludedir))" ""
override pkgincludedir : = $( pkgincludedir ) /postgresql
e n d i f
e n d i f
1997-02-04 09:53:45 +01:00
2000-10-08 23:13:27 +02:00
mandir := @mandir@
2000-06-27 02:32:06 +02:00
2000-10-08 23:13:27 +02:00
docdir := @docdir@
2004-05-22 02:34:51 +02:00
i f e q "$(findstring pgsql, $(docdir))" ""
i f e q "$(findstring postgres, $(docdir))" ""
override docdir : = $( docdir ) /postgresql
e n d i f
e n d i f
2008-02-17 17:36:43 +01:00
htmldir := @htmldir@
2000-06-27 02:32:06 +02:00
2001-06-02 20:25:18 +02:00
localedir := @localedir@
2001-05-25 16:28:58 +02:00
2005-09-27 19:39:35 +02:00
e l s e # PGXS case
2007-06-27 00:05:04 +02:00
# Extension makefiles should set PG_CONFIG, but older ones might not
i f n d e f P G _ C O N F I G
2006-07-20 11:30:18 +02:00
PG_CONFIG = pg_config
2007-06-27 00:05:04 +02:00
e n d i f
2006-07-20 11:30:18 +02:00
bindir := $( shell $( PG_CONFIG) --bindir)
datadir := $( shell $( PG_CONFIG) --sharedir)
sysconfdir := $( shell $( PG_CONFIG) --sysconfdir)
libdir := $( shell $( PG_CONFIG) --libdir)
pkglibdir := $( shell $( PG_CONFIG) --pkglibdir)
includedir := $( shell $( PG_CONFIG) --includedir)
pkgincludedir := $( shell $( PG_CONFIG) --pkgincludedir)
mandir := $( shell $( PG_CONFIG) --mandir)
docdir := $( shell $( PG_CONFIG) --docdir)
localedir := $( shell $( PG_CONFIG) --localedir)
2005-09-27 19:39:35 +02:00
e n d i f # PGXS
# These derived path variables aren't separately configurable.
includedir_server = $( pkgincludedir) /server
includedir_internal = $( pkgincludedir) /internal
2004-07-30 14:26:40 +02:00
pgxsdir = $( pkglibdir) /pgxs
2018-03-28 22:19:08 +02:00
bitcodedir = $( pkglibdir) /bitcode
2004-07-30 14:26:40 +02:00
1998-10-06 07:42:58 +02:00
2000-10-08 23:13:27 +02:00
##########################################################################
1997-02-04 09:53:45 +01:00
#
2000-10-08 23:13:27 +02:00
# Features
1997-02-04 09:53:45 +01:00
#
2000-10-08 23:13:27 +02:00
# Records the choice of the various --enable-xxx and --with-xxx options.
1997-02-04 09:53:45 +01:00
2017-03-23 20:25:34 +01:00
with_icu = @with_icu@
2000-10-08 23:13:27 +02:00
with_perl = @with_perl@
with_python = @with_python@
with_tcl = @with_tcl@
2021-02-01 11:19:44 +01:00
with_ssl = @with_ssl@
2020-01-02 21:02:21 +01:00
with_readline = @with_readline@
2011-01-24 02:44:48 +01:00
with_selinux = @with_selinux@
2015-11-17 12:46:17 +01:00
with_systemd = @with_systemd@
2018-03-05 20:42:11 +01:00
with_gssapi = @with_gssapi@
with_krb_srvnam = @with_krb_srvnam@
2018-03-03 07:29:51 +01:00
with_ldap = @with_ldap@
2007-04-13 20:50:01 +02:00
with_libxml = @with_libxml@
2007-04-15 14:48:24 +02:00
with_libxslt = @with_libxslt@
2018-03-21 01:26:25 +01:00
with_llvm = @with_llvm@
2007-08-20 10:53:12 +02:00
with_system_tzdata = @with_system_tzdata@
2014-05-28 01:42:08 +02:00
with_uuid = @with_uuid@
2005-07-06 01:13:57 +02:00
with_zlib = @with_zlib@
2000-10-28 01:59:39 +02:00
enable_rpath = @enable_rpath@
2001-06-02 20:25:18 +02:00
enable_nls = @enable_nls@
2002-03-05 18:55:23 +01:00
enable_debug = @enable_debug@
2006-07-24 18:32:45 +02:00
enable_dtrace = @enable_dtrace@
2008-09-05 14:11:18 +02:00
enable_coverage = @enable_coverage@
Add backend support for injection points
Injection points are a new facility that makes possible for developers
to run custom code in pre-defined code paths. Its goal is to provide
ways to design and run advanced tests, for cases like:
- Race conditions, where processes need to do actions in a controlled
ordered manner.
- Forcing a state, like an ERROR, FATAL or even PANIC for OOM, to force
recovery, etc.
- Arbitrary sleeps.
This implements some basics, and there are plans to extend it more in
the future depending on what's required. Hence, this commit adds a set
of routines in the backend that allows developers to attach, detach and
run injection points:
- A code path calling an injection point can be declared with the macro
INJECTION_POINT(name).
- InjectionPointAttach() and InjectionPointDetach() to respectively
attach and detach a callback to/from an injection point. An injection
point name is registered in a shmem hash table with a library name and a
function name, which will be used to load the callback attached to an
injection point when its code path is run.
Injection point names are just strings, so as an injection point can be
declared and run by out-of-core extensions and modules, with callbacks
defined in external libraries.
This facility is hidden behind a dedicated switch for ./configure and
meson, disabled by default.
Note that backends use a local cache to store callbacks already loaded,
cleaning up their cache if a callback has found to be removed on a
best-effort basis. This could be refined further but any tests but what
we have here was fine with the tests I've written while implementing
these backend APIs.
Author: Michael Paquier, with doc suggestions from Ashutosh Bapat.
Reviewed-by: Ashutosh Bapat, Nathan Bossart, Álvaro Herrera, Dilip
Kumar, Amul Sul, Nazir Bilal Yavuz
Discussion: https://postgr.es/m/ZTiV8tn_MIb_H2rE@paquier.xyz
2024-01-22 02:15:50 +01:00
enable_injection_points = @enable_injection_points@
2014-11-02 15:14:36 +01:00
enable_tap_tests = @enable_tap_tests@
1997-02-04 09:53:45 +01:00
2001-07-10 18:33:02 +02:00
python_includespec = @python_includespec@
2004-10-11 21:32:19 +02:00
python_libdir = @python_libdir@
2001-05-12 19:49:32 +02:00
python_libspec = @python_libspec@
2004-10-11 21:32:19 +02:00
python_additional_libs = @python_additional_libs@
2009-12-15 23:59:55 +01:00
python_majorversion = @python_majorversion@
2004-10-06 11:20:41 +02:00
python_version = @python_version@
2000-06-27 02:32:06 +02:00
2000-07-09 15:14:19 +02:00
krb_srvtab = @krb_srvtab@
2017-03-23 20:25:34 +01:00
ICU_CFLAGS = @ICU_CFLAGS@
ICU_LIBS = @ICU_LIBS@
2002-05-24 20:10:17 +02:00
TCLSH = @TCLSH@
TCL_LIBS = @TCL_LIBS@
TCL_LIB_SPEC = @TCL_LIB_SPEC@
2002-12-30 18:19:54 +01:00
TCL_INCLUDE_SPEC = @TCL_INCLUDE_SPEC@
2002-05-24 20:10:17 +02:00
TCL_SHARED_BUILD = @TCL_SHARED_BUILD@
2004-04-23 20:15:55 +02:00
PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
PTHREAD_LIBS = @PTHREAD_LIBS@
2003-05-27 18:36:50 +02:00
2018-03-21 01:26:25 +01:00
LLVM_BINPATH = @LLVM_BINPATH@
CLANG = @CLANG@
BITCODE_CFLAGS = @BITCODE_CFLAGS@
BITCODE_CXXFLAGS = @BITCODE_CXXFLAGS@
1997-02-04 09:53:45 +01:00
2000-10-08 23:13:27 +02:00
##########################################################################
1997-02-04 09:53:45 +01:00
#
2000-10-08 23:13:27 +02:00
# Programs and flags
1997-02-04 09:53:45 +01:00
2000-10-08 23:13:27 +02:00
# Compilers
2000-06-27 02:32:06 +02:00
2000-10-08 23:13:27 +02:00
CPP = @CPP@
CPPFLAGS = @CPPFLAGS@
2018-11-02 23:54:00 +01:00
PG_SYSROOT = @PG_SYSROOT@
2004-07-30 14:26:40 +02:00
2017-08-10 02:28:49 +02:00
override CPPFLAGS : = $( ICU_CFLAGS ) $( CPPFLAGS )
2017-06-12 21:57:22 +02:00
2004-07-30 14:26:40 +02:00
i f d e f P G X S
override CPPFLAGS : = -I $( includedir_server ) -I $( includedir_internal ) $( CPPFLAGS )
e l s e # not PGXS
2001-07-15 13:20:01 +02:00
override CPPFLAGS : = -I $( top_srcdir ) /src /include $( CPPFLAGS )
i f d e f V P A T H
override CPPFLAGS : = -I $( top_builddir ) /src /include $( CPPFLAGS )
e n d i f
2004-07-30 14:26:40 +02:00
e n d i f # not PGXS
2000-10-08 23:13:27 +02:00
2000-10-20 23:04:27 +02:00
CC = @CC@
GCC = @GCC@
2008-10-29 17:06:47 +01:00
SUN_STUDIO_CC = @SUN_STUDIO_CC@
2018-03-20 23:41:15 +01:00
CXX = @CXX@
2000-10-20 23:04:27 +02:00
CFLAGS = @CFLAGS@
2019-10-21 18:32:35 +02:00
CFLAGS_SL = @CFLAGS_SL@
Default to hidden visibility for extension libraries where possible
Until now postgres built extension libraries with global visibility, i.e.
exporting all symbols. On the one platform where that behavior is not
natively available, namely windows, we emulate it by analyzing the input files
to the shared library and exporting all the symbols therein.
Not exporting all symbols is actually desirable, as it can improve loading
speed, reduces the likelihood of symbol conflicts and can improve intra
extension library function call performance. It also makes the non-windows
builds more similar to windows builds.
Additionally, with meson implementing the export-all-symbols behavior for
windows, turns out to be more verbose than desirable.
This patch adds support for hiding symbols by default and, to counteract that,
explicit symbol visibility annotation for compilers that support
__attribute__((visibility("default"))) and -fvisibility=hidden. That is
expected to be most, if not all, compilers except msvc (for which we already
support explicit symbol export annotations).
Now that extension library symbols are explicitly exported, we don't need to
export all symbols on windows anymore, hence remove that behavior from
src/tools/msvc. The supporting code can't be removed, as we still need to
export all symbols from the main postgres binary.
Author: Andres Freund <andres@anarazel.de>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/20211101020311.av6hphdl6xbjbuif@alap3.anarazel.de
2022-07-18 02:49:51 +02:00
# *_MODULE are for flags applied to extension libraries
CFLAGS_SL_MODULE = @CFLAGS_SL_MODULE@
CXXFLAGS_SL_MODULE = @CXXFLAGS_SL_MODULE@
2020-09-07 03:28:16 +02:00
CFLAGS_UNROLL_LOOPS = @CFLAGS_UNROLL_LOOPS@
CFLAGS_VECTORIZE = @CFLAGS_VECTORIZE@
Optimize pg_popcount() with AVX-512 instructions.
Presently, pg_popcount() processes data in 32-bit or 64-bit chunks
when possible. Newer hardware that supports AVX-512 instructions
can use 512-bit chunks, which provides a nice speedup, especially
for larger buffers. This commit introduces the infrastructure
required to detect compiler and CPU support for the required
AVX-512 intrinsic functions, and it adds a new pg_popcount()
implementation that uses these functions. If CPU support for this
optimized implementation is detected at runtime, a function pointer
is updated so that it is used by subsequent calls to pg_popcount().
Most of the existing in-tree calls to pg_popcount() should benefit
from these instructions, and calls with smaller buffers should at
least not regress compared to v16. The new infrastructure
introduced by this commit can also be used to optimize
visibilitymap_count(), but that is left for a follow-up commit.
Co-authored-by: Paul Amonson, Ants Aasma
Reviewed-by: Matthias van de Meent, Tom Lane, Noah Misch, Akash Shankaran, Alvaro Herrera, Andres Freund, David Rowley
Discussion: https://postgr.es/m/BL1PR11MB5304097DF7EA81D04C33F3D1DCA6A%40BL1PR11MB5304.namprd11.prod.outlook.com
2024-04-07 04:56:23 +02:00
CFLAGS_POPCNT = @CFLAGS_POPCNT@
2022-12-02 03:46:55 +01:00
CFLAGS_CRC = @CFLAGS_CRC@
Optimize pg_popcount() with AVX-512 instructions.
Presently, pg_popcount() processes data in 32-bit or 64-bit chunks
when possible. Newer hardware that supports AVX-512 instructions
can use 512-bit chunks, which provides a nice speedup, especially
for larger buffers. This commit introduces the infrastructure
required to detect compiler and CPU support for the required
AVX-512 intrinsic functions, and it adds a new pg_popcount()
implementation that uses these functions. If CPU support for this
optimized implementation is detected at runtime, a function pointer
is updated so that it is used by subsequent calls to pg_popcount().
Most of the existing in-tree calls to pg_popcount() should benefit
from these instructions, and calls with smaller buffers should at
least not regress compared to v16. The new infrastructure
introduced by this commit can also be used to optimize
visibilitymap_count(), but that is left for a follow-up commit.
Co-authored-by: Paul Amonson, Ants Aasma
Reviewed-by: Matthias van de Meent, Tom Lane, Noah Misch, Akash Shankaran, Alvaro Herrera, Andres Freund, David Rowley
Discussion: https://postgr.es/m/BL1PR11MB5304097DF7EA81D04C33F3D1DCA6A%40BL1PR11MB5304.namprd11.prod.outlook.com
2024-04-07 04:56:23 +02:00
CFLAGS_XSAVE = @CFLAGS_XSAVE@
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
PERMIT_DECLARATION_AFTER_STATEMENT = @PERMIT_DECLARATION_AFTER_STATEMENT@
2018-03-20 23:41:15 +01:00
CXXFLAGS = @CXXFLAGS@
2000-06-27 02:32:06 +02:00
2018-03-21 01:26:25 +01:00
LLVM_CPPFLAGS = @LLVM_CPPFLAGS@
LLVM_CFLAGS = @LLVM_CFLAGS@
LLVM_CXXFLAGS = @LLVM_CXXFLAGS@
2000-10-08 23:13:27 +02:00
# Kind-of compilers
1997-02-04 09:53:45 +01:00
2008-08-29 15:02:33 +02:00
BISON = @BISON@
BISONFLAGS = @BISONFLAGS@ $( YFLAGS)
2000-08-28 13:53:23 +02:00
FLEX = @FLEX@
FLEXFLAGS = @FLEXFLAGS@ $( LFLAGS)
2006-07-24 18:32:45 +02:00
DTRACE = @DTRACE@
DTRACEFLAGS = @DTRACEFLAGS@
2009-01-05 11:25:59 +01:00
ZIC = @ZIC@
2000-10-08 23:13:27 +02:00
# Linking
2008-12-07 09:36:22 +01:00
AR = @AR@
autoconf: Rely on ar supporting index creation
This way we don't need RANLIB anymore, making it a bit simpler for the meson
build to generate Makefile.global for PGXS compatibility.
FreeBSD, NetBSD, OpenBSD, the only platforms where we didn't use AROPT=crs,
all have supported the 's' option for a long time.
On macOS we ran ranlib after installing a static library. This was added a
long time ago, in 58ad65ec2def. I cannot reproduce an issue in more recent
macOS versions. This is removed now.
Based on discussion with Tom, I left the 'touch' at the end of static
libraries generation, added in 826eff57c4c, in place. While it looks like
current versions of Apple's ar/ranlib don't need it, it was needed not too
long ago.
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/20221005200710.luvw5evhwf6clig6@awork3.anarazel.de
2022-10-07 20:53:39 +02:00
AROPT = crs
2000-10-08 23:13:27 +02:00
LIBS = @LIBS@
2006-09-09 05:15:40 +02:00
LDAP_LIBS_FE = @LDAP_LIBS_FE@
LDAP_LIBS_BE = @LDAP_LIBS_BE@
2014-05-28 01:42:08 +02:00
UUID_LIBS = @UUID_LIBS@
2018-03-21 01:26:25 +01:00
LLVM_LIBS = @LLVM_LIBS@
2010-07-07 00:03:05 +02:00
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
# It's critical that within LDFLAGS, all -L switches pointing to build-tree
# directories come before any -L switches pointing to external directories.
# Otherwise it's possible for, e.g., a platform-provided copy of libpq.so
# to get linked in place of the one we've built. Therefore we adopt the
# convention that the first component of LDFLAGS is an extra variable
# LDFLAGS_INTERNAL, and -L and -l switches for PG's own libraries must be
# put into LDFLAGS_INTERNAL, so they will appear ahead of those for external
# libraries.
#
# We need LDFLAGS and LDFLAGS_INTERNAL to be "recursively expanded" variables,
# else adjustments to, e.g., rpathdir don't work right. So we must NOT do
# "LDFLAGS := something" anywhere, ditto for LDFLAGS_INTERNAL.
# These initial assignments must be "=" type, and elsewhere we must only do
# "LDFLAGS += something" or "LDFLAGS_INTERNAL += something".
2010-07-07 00:03:05 +02:00
i f d e f P G X S
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$( libdir)
2010-07-07 00:03:05 +02:00
e l s e
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/port -L$( top_builddir) /src/common
2010-07-07 00:03:05 +02:00
e n d i f
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 = $( LDFLAGS_INTERNAL) @LDFLAGS@
2010-07-07 00:03:05 +02:00
2010-07-05 20:54:38 +02:00
LDFLAGS_EX = @LDFLAGS_EX@
2022-12-07 03:55:28 +01:00
LDFLAGS_EX_BE = @LDFLAGS_EX_BE@
2010-07-07 00:03:05 +02:00
# LDFLAGS_SL might have already been assigned by calling makefile
LDFLAGS_SL += @LDFLAGS_SL@
2008-12-07 09:36:22 +01:00
WINDRES = @WINDRES@
2000-09-27 17:17:57 +02:00
X = @EXEEXT@
2000-06-27 02:32:06 +02:00
2010-11-23 21:27:50 +01:00
# Perl
2001-08-27 00:28:04 +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
# quoted to protect pathname with spaces
PERL = '@PERL@'
2002-05-28 18:57:53 +02:00
perl_archlibexp = @perl_archlibexp@
perl_privlibexp = @perl_privlibexp@
Still further rethinking of build changes for macOS Mojave.
To avoid the sorts of problems complained of by Jakob Egger, it'd be
best if configure didn't emit any references to the sysroot path at all.
In the case of PL/Tcl, we can do that just by keeping our hands off the
TCL_INCLUDE_SPEC string altogether. In the case of PL/Perl, we need to
substitute -iwithsysroot for -I in the compile commands, which is easily
handled if we change to using a configure output variable that includes
the switch not only the directory name. Since PL/Tcl and PL/Python
already do it like that, this seems like good consistency cleanup anyway.
Hence, this replaces the advice given to Perl-related extensions in commit
5e2217131; instead of writing "-I$(perl_archlibexp)/CORE", they should
just write "$(perl_includespec)". (The old way continues to work, but not
on recent macOS.)
It's still the case that configure needs to be aware of the sysroot
path internally, but that's cleaner than what we had before.
As before, back-patch to all supported versions.
Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us
2018-10-18 20:55:23 +02:00
perl_includespec = @perl_includespec@
PL/Perl portability fix: absorb relevant -D switches from Perl.
The Perl documentation is very clear that stuff calling libperl should
be built with the compiler switches shown by Perl's $Config{ccflags}.
We'd been ignoring that up to now, and mostly getting away with it,
but recent Perl versions contain ABI compatibility cross-checks that
fail on some builds because of this omission. In particular the
sizeof(PerlInterpreter) can come out different due to some fields being
added or removed; which means we have a live ABI hazard that we'd better
fix rather than continuing to sweep it under the rug.
However, it still seems like a bad idea to just absorb $Config{ccflags}
verbatim. In some environments Perl was built with a different compiler
that doesn't even use the same switch syntax. -D switch syntax is pretty
universal though, and absorbing Perl's -D switches really ought to be
enough to fix the problem.
Furthermore, Perl likes to inject stuff like -D_LARGEFILE_SOURCE and
-D_FILE_OFFSET_BITS=64 into $Config{ccflags}, which affect libc ABIs on
platforms where they're relevant. Adopting those seems dangerous too.
It's unclear whether a build wherein Perl and Postgres have different ideas
of sizeof(off_t) etc would work, or whether anyone would care about making
it work. But it's dead certain that having different stdio ABIs in
core Postgres and PL/Perl will not work; we've seen that movie before.
Therefore, let's also ignore -D switches for symbols beginning with
underscore. The symbols that we actually need to import should be the ones
mentioned in perl.h's PL_bincompat_options stanza, and none of those start
with underscore, so this seems likely to work. (If it turns out not to
work everywhere, we could consider intersecting the symbols mentioned in
PL_bincompat_options with the -D switches. But that will be much more
complicated, so let's try this way first.)
This will need to be back-patched, but first let's see what the
buildfarm makes of it.
Ashutosh Sharma, some adjustments by me
Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 20:25:28 +02:00
perl_embed_ccflags = @perl_embed_ccflags@
2002-05-28 18:57:53 +02:00
perl_embed_ldflags = @perl_embed_ldflags@
2001-08-27 00:28:04 +02:00
2000-10-08 23:13:27 +02:00
# Miscellaneous
AWK = @AWK@
LN_S = @LN_S@
2001-06-02 20:25:18 +02:00
MSGFMT = @MSGFMT@
2013-09-11 20:34:28 +02:00
MSGFMT_FLAGS = @MSGFMT_FLAGS@
2001-06-02 20:25:18 +02:00
MSGMERGE = @MSGMERGE@
2022-10-20 21:01:05 +02:00
OPENSSL = @OPENSSL@
2000-10-08 23:13:27 +02:00
PYTHON = @PYTHON@
TAR = @TAR@
2001-06-02 20:25:18 +02:00
XGETTEXT = @XGETTEXT@
2000-10-08 23:13:27 +02:00
2001-09-18 01:00:27 +02:00
GZIP = gzip
BZIP2 = bzip2
2022-02-14 02:40:34 +01:00
LZ4 = @LZ4@
2022-02-18 19:40:31 +01:00
ZSTD = @ZSTD@
2001-09-18 01:00:27 +02:00
2020-01-09 09:54:47 +01:00
DOWNLOAD = wget -O $@ --no-use-server-timestamps
#DOWNLOAD = curl -o $@
# Unicode data information
# Before each major release, update these and run make update-unicode.
# Pick a release from here: <https://www.unicode.org/Public/>. Note
# that the most recent release listed there is often a pre-release;
# don't pick that one, except for testing.
2023-09-18 07:26:34 +02:00
UNICODE_VERSION = 15.1.0
2020-01-09 09:54:47 +01:00
# Pick a release from here: <http://cldr.unicode.org/index/downloads>
2023-04-13 22:10:08 +02:00
CLDR_VERSION = 43
2020-01-09 09:54:47 +01:00
2018-04-09 22:42:02 +02:00
# Tree-wide build support
# Just about every code subdirectory wants to have the generated headers
# available before building, but we don't want parallel makes all trying
# to build the same headers. These rules, together with the recursion rules
# below, ensure that we update the generated headers once, if needed,
2018-07-31 00:04:39 +02:00
# at the top level of any "make all/install/check/installcheck" request.
# If a particular subdirectory knows this isn't needed in itself or its
# children, it can set NO_GENERATED_HEADERS.
2018-04-09 22:42:02 +02:00
2018-07-31 00:04:39 +02:00
all install check installcheck : submake -generated -headers
2018-04-09 22:42:02 +02:00
.PHONY : submake -generated -headers
submake-generated-headers :
i f n d e f N O _ G E N E R A T E D _ H E A D E R S
i f e q ( $( MAKELEVEL ) , 0 )
$( MAKE) -C $( top_builddir) /src/backend generated-headers
e n d i f
e n d i f
2014-04-15 03:33:46 +02:00
# Testing
2018-04-09 22:42:02 +02:00
# In much the same way as above, these rules ensure that we build a temp
# install tree just once in any recursive "make check". The additional test
# on abs_top_builddir prevents doing anything foolish to the root directory.
2015-04-23 14:59:52 +02:00
check : temp -install
.PHONY : temp -install
2018-04-09 22:42:02 +02:00
2023-08-24 23:17:03 +02:00
# prepend to path if already set, else just set it
d e f i n e a d d _ t o _ p a t h
$(1) = " $( if $( $( 1) ) ,$( 2) :$$ $( 1) ,$( 2) ) "
e n d e f
# platform-specific environment variable to set shared library path
# individual ports can override this later, this is the default name
ld_library_path_var = LD_LIBRARY_PATH
# with_temp_install_extra is for individual ports to define if they
# need something more here. If not defined then the expansion does
# nothing.
with_temp_install = \
PATH = " $( abs_top_builddir) /tmp_install $( bindir) : $( CURDIR) : $$ PATH " \
$( call add_to_path,$( strip $( ld_library_path_var) ) ,$( abs_top_builddir) /tmp_install$( libdir) ) \
INITDB_TEMPLATE = '$(abs_top_builddir)' /tmp_install/initdb-template \
$( with_temp_install_extra)
2018-04-11 19:18:50 +02:00
temp-install : | submake -generated -headers
2015-05-12 18:30:50 +02:00
i f n d e f N O _ T E M P _ I N S T A L L
2015-09-28 16:47:05 +02:00
i f n e q ( $( abs_top_builddir ) , )
2015-04-23 14:59:52 +02:00
i f e q ( $( MAKELEVEL ) , 0 )
rm -rf '$(abs_top_builddir)' /tmp_install
2015-07-23 15:44:20 +02:00
$( MKDIR_P) '$(abs_top_builddir)' /tmp_install/log
$( MAKE) -C '$(top_builddir)' DESTDIR = '$(abs_top_builddir)' /tmp_install install >'$(abs_top_builddir)' /tmp_install/log/install.log 2>& 1
2018-12-31 22:54:38 +01:00
$( MAKE) -j1 $( if $( CHECKPREP_TOP) ,-C $( CHECKPREP_TOP) ,) checkprep >>'$(abs_top_builddir)' /tmp_install/log/install.log 2>& 1
2023-08-24 23:17:03 +02:00
2023-12-22 00:10:13 +01:00
$( with_temp_install) initdb --auth trust --no-sync --no-instructions --lc-messages= C --no-clean '$(abs_top_builddir)' /tmp_install/initdb-template >>'$(abs_top_builddir)' /tmp_install/log/initdb-template.log 2>& 1
2015-04-23 14:59:52 +02:00
e n d i f
2015-05-12 17:01:25 +02:00
e n d i f
2015-09-28 16:47:05 +02:00
e n d i f
2015-04-23 14:59:52 +02:00
2018-12-31 22:54:38 +01:00
# Tasks to run serially at the end of temp-install. Some EXTRA_INSTALL
# entries appear more than once in the tree, and parallel installs of the same
# file can fail with EEXIST.
checkprep :
$( if $( EXTRA_INSTALL) ,for extra in $( EXTRA_INSTALL) ; do $( MAKE) -C '$(top_builddir)' /$$ extra DESTDIR = '$(abs_top_builddir)' /tmp_install install || exit; done )
2014-04-15 03:33:46 +02:00
PROVE = @PROVE@
2016-10-07 20:48:21 +02:00
# There are common routines in src/test/perl, and some test suites have
# extra perl modules in their own directory.
PG_PROVE_FLAGS = -I $( top_srcdir) /src/test/perl/ -I $( srcdir)
2017-05-12 17:11:49 +02:00
# User-supplied prove flags such as --verbose can be provided in PROVE_FLAGS.
2017-06-10 16:19:06 +02:00
PROVE_FLAGS =
2014-04-15 03:33:46 +02:00
2014-11-02 15:14:36 +01:00
i f e q ( $( enable_tap_tests ) , y e s )
2021-07-01 14:29:10 +02:00
i f n d e f P G X S
2014-04-15 03:33:46 +02:00
d e f i n e p r o v e _ i n s t a l l c h e c k
2023-03-31 13:00:02 +02:00
e c h o "# +++ tap install-check in $(subdir) +++" & & \
2022-02-27 01:51:47 +01:00
r m - r f '$(CURDIR)' / t m p _ c h e c k & & \
$( MKDIR_P ) '$(CURDIR)' / t m p _ c h e c k & & \
2021-07-01 14:29:10 +02:00
c d $( srcdir ) & & \
2022-09-20 03:03:17 +02:00
TESTLOGDIR = '$(CURDIR)/tmp_check/log' \
TESTDATADIR = '$(CURDIR)/tmp_check' \
PATH = " $( bindir) : $( CURDIR) : $$ PATH " \
2021-10-22 15:11:52 +02:00
PGPORT = '6$(DEF_PGPORT)' top_builddir = '$(CURDIR)/$(top_builddir)' \
2021-07-01 14:29:10 +02:00
PG_REGRESS = '$(CURDIR)/$(top_builddir)/src/test/regress/pg_regress' \
$( PROVE) $( PG_PROVE_FLAGS) $( PROVE_FLAGS) $( if $( PROVE_TESTS) ,$( PROVE_TESTS) ,t/*.pl)
2014-04-15 03:33:46 +02:00
e n d e f
2021-07-01 14:29:10 +02:00
e l s e # PGXS case
d e f i n e p r o v e _ i n s t a l l c h e c k
2023-03-31 13:00:02 +02:00
e c h o "# +++ tap install-check in $(subdir) +++" & & \
2022-02-27 01:51:47 +01:00
r m - r f '$(CURDIR)' / t m p _ c h e c k & & \
$( MKDIR_P ) '$(CURDIR)' / t m p _ c h e c k & & \
2021-07-01 14:29:10 +02:00
c d $( srcdir ) & & \
2022-09-20 03:03:17 +02:00
TESTLOGDIR = '$(CURDIR)/tmp_check/log' \
TESTDATADIR = '$(CURDIR)/tmp_check' \
PATH = " $( bindir) : $( CURDIR) : $$ PATH " \
2023-05-05 06:29:49 +02:00
PGPORT = '6$(DEF_PGPORT)' \
2021-07-01 14:29:10 +02:00
PG_REGRESS = '$(top_builddir)/src/test/regress/pg_regress' \
$( PROVE) $( PG_PROVE_FLAGS) $( PROVE_FLAGS) $( if $( PROVE_TESTS) ,$( PROVE_TESTS) ,t/*.pl)
e n d e f
e n d i f # PGXS
2014-04-15 03:33:46 +02:00
d e f i n e p r o v e _ c h e c k
2023-03-31 13:00:02 +02:00
e c h o "# +++ tap check in $(subdir) +++" & & \
2022-02-27 01:51:47 +01:00
r m - r f '$(CURDIR)' / t m p _ c h e c k & & \
$( MKDIR_P ) '$(CURDIR)' / t m p _ c h e c k & & \
2021-07-01 14:29:10 +02:00
c d $( srcdir ) & & \
2022-09-20 03:03:17 +02:00
TESTLOGDIR = '$(CURDIR)/tmp_check/log' \
TESTDATADIR = '$(CURDIR)/tmp_check' \
$( with_temp_install) \
2022-11-20 15:51:50 +01:00
PGPORT = '6$(DEF_PGPORT)' top_builddir = '$(CURDIR)/$(top_builddir)' \
2021-07-01 14:29:10 +02:00
PG_REGRESS = '$(CURDIR)/$(top_builddir)/src/test/regress/pg_regress' \
$( PROVE) $( PG_PROVE_FLAGS) $( PROVE_FLAGS) $( if $( PROVE_TESTS) ,$( PROVE_TESTS) ,t/*.pl)
2014-04-15 03:33:46 +02:00
e n d e f
2014-11-02 15:14:36 +01:00
e l s e
2021-10-04 11:46:29 +02:00
prove_installcheck = @echo "TAP tests not enabled. Try configuring with --enable-tap-tests"
2014-11-02 15:14:36 +01:00
prove_check = $( prove_installcheck)
e n d i f
2000-10-08 23:13:27 +02:00
# Installation.
2012-06-28 19:05:36 +02:00
install_bin = @install_bin@
2012-06-27 12:40:51 +02:00
install_sh = $( SHELL) $( top_srcdir) /config/install-sh -c
2012-06-28 19:05:36 +02:00
INSTALL = $( if $( use_install_sh) ,$( install_sh) ,$( if $( install_bin) ,$( install_bin) ,$( install_sh) ) )
2000-10-08 23:13:27 +02:00
2005-03-26 00:22:54 +01:00
INSTALL_SCRIPT_MODE = 755
INSTALL_DATA_MODE = 644
2002-04-10 18:45:25 +02:00
INSTALL_PROGRAM = $( INSTALL_PROGRAM_ENV) $( INSTALL) $( INSTALL_STRIP_FLAG)
2005-03-26 00:22:54 +01:00
INSTALL_SCRIPT = $( INSTALL) -m $( INSTALL_SCRIPT_MODE)
INSTALL_DATA = $( INSTALL) -m $( INSTALL_DATA_MODE)
2002-04-10 18:45:25 +02:00
INSTALL_STLIB = $( INSTALL_STLIB_ENV) $( INSTALL_DATA) $( INSTALL_STRIP_FLAG)
INSTALL_SHLIB = $( INSTALL_SHLIB_ENV) $( INSTALL) $( INSTALL_SHLIB_OPTS) $( INSTALL_STRIP_FLAG)
2001-03-10 11:38:59 +01:00
# Override in Makefile.port if necessary
INSTALL_SHLIB_OPTS = -m 755
2000-10-08 23:13:27 +02:00
2009-08-27 00:24:44 +02:00
MKDIR_P = @MKDIR_P@
2000-10-08 23:13:27 +02:00
missing = $( SHELL) $( top_srcdir) /config/missing
1997-02-04 09:53:45 +01:00
2002-04-10 18:45:25 +02:00
STRIP = @STRIP@
STRIP_STATIC_LIB = @STRIP_STATIC_LIB@
STRIP_SHARED_LIB = @STRIP_SHARED_LIB@
2000-11-05 22:04:07 +01:00
# Documentation
2014-09-14 02:14:17 +02:00
DBTOEPUB = @DBTOEPUB@
2017-04-07 04:03:52 +02:00
FOP = @FOP@
doc: Check DocBook XML validity during the build
Building the documentation with XSLT does not check the DTD, like a
DSSSL build would. One can often get away with having invalid XML, but
the stylesheets might then create incorrect output, as they are not
designed to handle that. Therefore, check the validity of the XML
against the DTD, using xmllint, during the build.
Add xmllint detection to configure, and add some documentation.
xmllint comes with libxml2, which is already in use, but it might be in
a separate package, such as libxml2-utils on Debian.
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>
2014-10-21 20:46:38 +02:00
XMLLINT = @XMLLINT@
2009-08-05 00:04:37 +02:00
XSLTPROC = @XSLTPROC@
2000-11-05 22:04:07 +01:00
2008-09-05 14:11:18 +02:00
# Code coverage
GCOV = @GCOV@
LCOV = @LCOV@
GENHTML = @GENHTML@
2001-02-07 21:13:27 +01:00
# Feature settings
DEF_PGPORT = @default_port@
2001-06-02 20:25:18 +02:00
WANTED_LANGUAGES = @WANTED_LANGUAGES@
2001-02-07 21:13:27 +01:00
2000-10-08 23:13:27 +02:00
##########################################################################
1998-10-19 02:00:51 +02:00
#
# Additional platform-specific settings
#
2000-10-08 23:13:27 +02:00
# Name of the "template"
1998-10-19 02:00:51 +02:00
PORTNAME = @PORTNAME@
2000-09-29 19:17:41 +02:00
2009-01-05 10:54:13 +01:00
build_os = @build_os@
2000-09-29 19:17:41 +02:00
host_tuple = @host@
host_os = @host_os@
host_cpu = @host_cpu@
1998-10-19 02:00:51 +02:00
2006-10-08 19:15:34 +02:00
# Backend stack size limit has to be hard-wired on Windows (it's in bytes)
WIN32_STACK_RLIMIT = 4194304
2022-03-25 08:44:31 +01:00
DLSUFFIX = @DLSUFFIX@
2000-10-08 23:13:27 +02:00
# Pull in platform-specific magic
2000-08-31 18:12:35 +02:00
i n c l u d e $( top_builddir ) / s r c / M a k e f i l e . p o r t
1997-03-25 08:16:36 +01:00
2004-11-19 01:41:39 +01:00
# Set up rpath if enabled. By default it will point to our libdir,
# but individual Makefiles can force other rpath paths if needed.
rpathdir = $( libdir)
2000-10-28 01:59:39 +02:00
i f e q ( $( enable_rpath ) , y e s )
LDFLAGS += $( rpath)
e n d i f
2000-10-08 23:13:27 +02:00
2019-01-13 21:59:35 +01:00
# Show the DLSUFFIX to build scripts (e.g. buildfarm)
.PHONY : show_dl_suffix
2019-01-13 22:43:14 +01:00
show_dl_suffix :
2019-01-13 21:59:35 +01:00
@echo $( DLSUFFIX)
2002-07-27 22:10:05 +02:00
2000-10-08 23:13:27 +02:00
##########################################################################
#
# Some variables needed to find some client interfaces
2004-08-20 22:13:10 +02:00
i f d e f P G X S
# some contribs assumes headers and libs are in the source tree...
libpq_srcdir = $( includedir)
libpq_builddir = $( libdir)
e l s e
2000-10-08 23:13:27 +02:00
libpq_srcdir = $( top_srcdir) /src/interfaces/libpq
libpq_builddir = $( top_builddir) /src/interfaces/libpq
2004-08-20 22:13:10 +02:00
e n d i f
2018-09-28 20:28:19 +02:00
# How to link to libpq. (This macro may be used as-is by backend extensions.
# Client-side code should go through libpq_pgport or libpq_pgport_shlib,
# instead.)
2007-02-09 16:56:00 +01:00
libpq = -L$( libpq_builddir) -lpq
2010-11-23 21:27:50 +01:00
2018-09-28 20:28:19 +02:00
# libpq_pgport is for use by client executables (not libraries) that use libpq.
Suppress macOS warnings about duplicate libraries in link commands.
As of Xcode 15 (macOS Sonoma), the linker complains about duplicate
references to the same library. We see warnings about libpgport and
libpgcommon being duplicated in many client executables. This is a
consequence of the hack introduced in commit 6b7ef076b to list
libpgport before libpq while not removing it from $(LIBS).
(Commit 8396447cd later applied the same rule to libpgcommon.)
The concern in 6b7ef076b was to ensure that the client executable
wouldn't unintentionally depend on pgport functions from libpq.
That concern is obsolete on any platform for which we can do symbol
export control, because if we can then the pgport functions in libpq
won't be exposed anyway. Hence, we can fix this problem by just
removing libpgport and libpgcommon from $(libpq_pgport), and letting
clients depend on the occurrences in $(LIBS).
In the back branches, do that only on macOS (which we know has
symbol export control). In HEAD, let's be more aggressive and
remove the extra libraries everywhere. The only still-supported
platforms that lack export control are MinGW/Cygwin, and it
doesn't seem worth sweating over ABI stability details for those
(or if somebody does care, it'd probably be possible to perform
symbol export control for those too). As well as being simpler,
this might give some microscopic improvement in build time.
The meson build system is not changed here, as it doesn't have
this particular disease, though it does have some related issues
that we'll fix separately.
Discussion: https://postgr.es/m/467042.1695766998@sss.pgh.pa.us
2023-09-29 20:07:30 +02:00
# We used to use this to force libpgport and libpgcommon to be linked before
# libpq, ensuring that clients would pull symbols from those libraries rather
# than possibly getting them from libpq (and thereby having an unwanted
# dependency on which symbols libpq uses). However, now that we can prevent
# libpq from exporting those symbols on all platforms of interest, we don't
# worry about that anymore. The previous technique resulted in duplicate
# libraries in link commands, since those libraries also appear in $(LIBS).
# Some platforms warn about that, so avoiding those warnings is now more
# important. Hence, $(libpq_pgport) is now equivalent to $(libpq), but we
# still recommend using it for client executables in case some other reason
# appears to handle them differently.
libpq_pgport = $( libpq)
2018-09-28 20:28:19 +02:00
# libpq_pgport_shlib is the same idea, but for use in client shared libraries.
Suppress macOS warnings about duplicate libraries in link commands.
As of Xcode 15 (macOS Sonoma), the linker complains about duplicate
references to the same library. We see warnings about libpgport and
libpgcommon being duplicated in many client executables. This is a
consequence of the hack introduced in commit 6b7ef076b to list
libpgport before libpq while not removing it from $(LIBS).
(Commit 8396447cd later applied the same rule to libpgcommon.)
The concern in 6b7ef076b was to ensure that the client executable
wouldn't unintentionally depend on pgport functions from libpq.
That concern is obsolete on any platform for which we can do symbol
export control, because if we can then the pgport functions in libpq
won't be exposed anyway. Hence, we can fix this problem by just
removing libpgport and libpgcommon from $(libpq_pgport), and letting
clients depend on the occurrences in $(LIBS).
In the back branches, do that only on macOS (which we know has
symbol export control). In HEAD, let's be more aggressive and
remove the extra libraries everywhere. The only still-supported
platforms that lack export control are MinGW/Cygwin, and it
doesn't seem worth sweating over ABI stability details for those
(or if somebody does care, it'd probably be possible to perform
symbol export control for those too). As well as being simpler,
this might give some microscopic improvement in build time.
The meson build system is not changed here, as it doesn't have
this particular disease, though it does have some related issues
that we'll fix separately.
Discussion: https://postgr.es/m/467042.1695766998@sss.pgh.pa.us
2023-09-29 20:07:30 +02:00
# We need those clients to use the shlib variants. (Ideally, users of this
# macro would strip libpgport and libpgcommon from $(LIBS), but no harm is
# done if they don't, since they will have satisfied all their references
# from these libraries.)
2005-03-25 19:17:14 +01:00
i f d e f P G X S
2018-09-28 20:28:19 +02:00
libpq_pgport_shlib = -L$( libdir) -lpgcommon_shlib -lpgport_shlib $( libpq)
2005-03-25 19:17:14 +01:00
e l s e
2018-09-28 20:28:19 +02:00
libpq_pgport_shlib = -L$( top_builddir) /src/common -lpgcommon_shlib -L$( top_builddir) /src/port -lpgport_shlib $( libpq)
2005-03-25 19:17:14 +01:00
e n d i f
2014-02-11 18:10:52 +01:00
# Cygwin seems to need ldap libraries to be mentioned here, too
i f e q ( $( PORTNAME ) , c y g w i n )
libpq_pgport += $( LDAP_LIBS_FE)
e n d i f
2014-12-04 13:58:12 +01:00
2016-07-01 21:08:55 +02:00
##########################################################################
#
# Commonly used submake targets
2018-04-11 19:18:50 +02:00
submake-libpq : | submake -generated -headers
2002-07-27 22:10:05 +02:00
$( MAKE) -C $( libpq_builddir) all
2018-04-10 22:14:55 +02:00
submake-libpgport : | submake -generated -headers
2002-07-27 22:10:05 +02:00
$( MAKE) -C $( top_builddir) /src/port all
Create libpgcommon, and move pg_malloc et al to it
libpgcommon is a new static library to allow sharing code among the
various frontend programs and backend; this lets us eliminate duplicate
implementations of common routines. We avoid libpgport, because that's
intended as a place for porting issues; per discussion, it seems better
to keep them separate.
The first use case, and the only implemented by this patch, is pg_malloc
and friends, which many frontend programs were already using.
At the same time, we can use this to provide palloc emulation functions
for the frontend; this way, some palloc-using files in the backend can
also be used by the frontend cleanly. To do this, we change palloc() in
the backend to be a function instead of a macro on top of
MemoryContextAlloc(). This was previously believed to cause loss of
performance, but this implementation has been tweaked by Tom and Andres
so that on modern compilers it provides a slight improvement over the
previous one.
This lets us clean up some places that were already with
localized hacks.
Most of the pg_malloc/palloc changes in this patch were authored by
Andres Freund. Zoltán Böszörményi also independently provided a form of
that. libpgcommon infrastructure was authored by Álvaro.
2013-02-12 14:33:40 +01:00
$( MAKE) -C $( top_builddir) /src/common all
2002-07-27 22:10:05 +02:00
2018-04-10 22:14:55 +02:00
submake-libpgfeutils : | submake -generated -headers
2016-03-24 20:55:44 +01:00
$( MAKE) -C $( top_builddir) /src/port all
$( MAKE) -C $( top_builddir) /src/common all
$( MAKE) -C $( top_builddir) /src/fe_utils all
2018-04-09 22:42:02 +02:00
.PHONY : submake -libpq submake -libpgport submake -libpgfeutils
2002-07-27 22:10:05 +02:00
2000-10-08 23:13:27 +02:00
2011-02-14 20:52:32 +01:00
##########################################################################
#
# Testing support
2019-04-04 02:06:01 +02:00
i f n e q ( $( USE_MODULE_DB ) , )
PL_TESTDB = pl_regression_$( NAME)
ifneq ( $( MODULE_big) ,)
CONTRIB_TESTDB = contrib_regression_$( MODULE_big)
ISOLATION_TESTDB = isolation_regression_$( MODULE_big)
2012-12-11 17:52:45 +01:00
else
2019-04-04 02:06:01 +02:00
ifneq ( $( MODULES) ,)
CONTRIB_TESTDB = contrib_regression_$( word 1,$( MODULES) )
ISOLATION_TESTDB = isolation_regression_$( word 1,$( MODULES) )
else
CONTRIB_TESTDB = contrib_regression_$( word 1,$( REGRESS) )
ISOLATION_TESTDB = isolation_regression_$( word 1,$( ISOLATION) )
endif
2012-12-11 17:52:45 +01:00
endif
2019-04-04 02:06:01 +02:00
e l s e
PL_TESTDB = pl_regression
CONTRIB_TESTDB = contrib_regression
ISOLATION_TESTDB = isolation_regression
2012-12-11 17:52:45 +01:00
e n d i f
2011-02-14 20:52:32 +01:00
2011-04-15 07:42:05 +02:00
i f d e f N O _ L O C A L E
NOLOCALE += --no-locale
e n d i f
2016-02-27 18:28:21 +01:00
# file with extra config for temp build
TEMP_CONF =
i f d e f T E M P _ C O N F I G
TEMP_CONF += --temp-config= $( TEMP_CONFIG)
e n d i f
2011-04-15 07:42:05 +02:00
pg_regress_locale_flags = $( if $( ENCODING) ,--encoding= $( ENCODING) ) $( NOLOCALE)
2017-03-14 23:56:17 +01:00
pg_regress_clean_files = results/ regression.diffs regression.out tmp_check/ tmp_check_iso/ log/ output_iso/
pg_regress_check = \
2023-03-31 13:00:02 +02:00
echo " \# +++ regress check in $( subdir) +++ " && \
2017-03-14 23:56:17 +01:00
$( with_temp_install) \
$( top_builddir) /src/test/regress/pg_regress \
--temp-instance= ./tmp_check \
--inputdir= $( srcdir) \
2017-03-16 03:03:29 +01:00
--bindir= \
2017-03-14 23:56:17 +01:00
$( TEMP_CONF) \
2017-03-16 03:03:29 +01:00
$( pg_regress_locale_flags) $( EXTRA_REGRESS_OPTS)
2017-03-14 23:56:17 +01:00
pg_regress_installcheck = \
2023-03-31 13:00:02 +02:00
echo " \# +++ regress install-check in $( subdir) +++ " && \
2017-03-14 23:56:17 +01:00
$( top_builddir) /src/test/regress/pg_regress \
--inputdir= $( srcdir) \
2017-03-16 03:03:29 +01:00
--bindir= '$(bindir)' \
$( pg_regress_locale_flags) $( EXTRA_REGRESS_OPTS)
2017-03-14 23:56:17 +01:00
pg_isolation_regress_check = \
2023-03-31 13:00:02 +02:00
echo " \# +++ isolation check in $( subdir) +++ " && \
2017-03-14 23:56:17 +01:00
$( with_temp_install) \
$( top_builddir) /src/test/isolation/pg_isolation_regress \
--temp-instance= ./tmp_check_iso \
--inputdir= $( srcdir) --outputdir= output_iso \
2017-03-16 03:03:29 +01:00
--bindir= \
2017-03-14 23:56:17 +01:00
$( TEMP_CONF) \
2017-03-16 03:03:29 +01:00
$( pg_regress_locale_flags) $( EXTRA_REGRESS_OPTS)
2017-03-14 23:56:17 +01:00
pg_isolation_regress_installcheck = \
2023-03-31 13:00:02 +02:00
echo " \# +++ isolation install-check in $( subdir) +++ " && \
2017-03-14 23:56:17 +01:00
$( top_builddir) /src/test/isolation/pg_isolation_regress \
2017-05-14 00:13:17 +02:00
--inputdir= $( srcdir) --outputdir= output_iso \
2017-03-16 03:03:29 +01:00
--bindir= '$(bindir)' \
2017-03-14 23:56:17 +01:00
$( pg_regress_locale_flags) $( EXTRA_REGRESS_OPTS)
2011-02-14 20:52:32 +01:00
2000-10-08 23:13:27 +02:00
##########################################################################
1997-03-25 08:16:36 +01:00
#
2000-10-08 23:13:27 +02:00
# Customization
1997-03-25 08:16:36 +01:00
#
1997-04-12 12:33:10 +02:00
# This includes your local customizations if Makefile.custom exists
# in the source directory. This file doesn't exist in the original
# distribution so that it doesn't get overwritten when you upgrade.
2000-10-08 23:13:27 +02:00
#
# NOTE: Makefile.custom is from the pre-Autoconf days of PostgreSQL.
# You are liable to shoot yourself in the foot if you use it without
# knowing exactly what you're doing. The preferred (and more
# reliable) method is to communicate what you want to do to the
# configure script, and leave the makefiles alone.
1997-03-25 08:16:36 +01:00
2000-10-08 23:13:27 +02:00
- i n c l u d e $( top_srcdir ) / s r c / M a k e f i l e . c u s t o m
1997-02-04 09:53:45 +01:00
i f n e q ( $( CUSTOM_INSTALL ) , )
INSTALL = $( CUSTOM_INSTALL)
e n d i f
i f n e q ( $( CUSTOM_CC ) , )
CC = $( CUSTOM_CC)
e n d i f
i f n e q ( $( CUSTOM_COPT ) , )
COPT = $( CUSTOM_COPT)
e n d i f
2017-02-17 22:11:02 +01:00
#
# These variables are meant to be set in the environment of "make"
# to add flags to whatever configure picked. Unlike the ones above,
# they are documented.
#
1997-02-04 09:53:45 +01:00
i f d e f C O P T
2004-12-16 18:48:29 +01:00
CFLAGS += $( COPT)
LDFLAGS += $( COPT)
1997-02-04 09:53:45 +01:00
e n d i f
i f d e f P R O F I L E
2004-12-16 18:48:29 +01:00
CFLAGS += $( PROFILE)
LDFLAGS += $( PROFILE)
1997-02-04 09:53:45 +01:00
e n d i f
2000-06-27 02:32:06 +02:00
2000-10-08 23:13:27 +02:00
##########################################################################
#
2005-08-02 21:02:32 +02:00
# substitute implementations of C library routines (see src/port/)
2010-07-07 00:03:05 +02:00
# note we already included -L.../src/port in LDFLAGS above
2000-10-08 23:13:27 +02:00
2007-09-29 00:25:49 +02:00
LIBOBJS = @LIBOBJS@
2002-07-27 22:10:05 +02:00
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 16:05:03 +02:00
# files needed for the chosen CRC-32C implementation
PG_CRC32C_OBJS = @PG_CRC32C_OBJS@
Optimize pg_popcount() with AVX-512 instructions.
Presently, pg_popcount() processes data in 32-bit or 64-bit chunks
when possible. Newer hardware that supports AVX-512 instructions
can use 512-bit chunks, which provides a nice speedup, especially
for larger buffers. This commit introduces the infrastructure
required to detect compiler and CPU support for the required
AVX-512 intrinsic functions, and it adds a new pg_popcount()
implementation that uses these functions. If CPU support for this
optimized implementation is detected at runtime, a function pointer
is updated so that it is used by subsequent calls to pg_popcount().
Most of the existing in-tree calls to pg_popcount() should benefit
from these instructions, and calls with smaller buffers should at
least not regress compared to v16. The new infrastructure
introduced by this commit can also be used to optimize
visibilitymap_count(), but that is left for a follow-up commit.
Co-authored-by: Paul Amonson, Ants Aasma
Reviewed-by: Matthias van de Meent, Tom Lane, Noah Misch, Akash Shankaran, Alvaro Herrera, Andres Freund, David Rowley
Discussion: https://postgr.es/m/BL1PR11MB5304097DF7EA81D04C33F3D1DCA6A%40BL1PR11MB5304.namprd11.prod.outlook.com
2024-04-07 04:56:23 +02:00
# files needed for the chosen popcount implementation
PG_POPCNT_OBJS = @PG_POPCNT_OBJS@
2013-10-18 03:52:54 +02:00
LIBS := -lpgcommon -lpgport $( LIBS)
2002-03-13 01:05:06 +01:00
2014-10-22 04:55:43 +02:00
# to make ws2_32.lib the last library
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
i f e q ( $( PORTNAME ) , w i n 3 2 )
2014-10-22 04:55:43 +02:00
LIBS += -lws2_32
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
e n d i f
2002-07-19 19:35:11 +02:00
# Not really standard libc functions, used by the backend.
2002-03-13 01:05:06 +01:00
TAS = @TAS@
2000-06-27 02:32:06 +02:00
2000-07-16 16:50:44 +02:00
2000-10-08 23:13:27 +02:00
##########################################################################
#
2001-09-18 01:00:27 +02:00
# Global targets and rules
2012-10-11 12:57:04 +02:00
%.c : %.l
$( FLEX) $( if $( FLEX_NO_BACKUP) ,-b) $( FLEXFLAGS) -o'$@' $<
@$( if $( FLEX_NO_BACKUP) ,if [ ` wc -l <lex.backup` -eq 1 ] ; then rm lex.backup; else echo "Scanner requires backup; see lex.backup." 1>& 2; exit 1; fi )
2017-02-19 22:41:51 +01:00
$( if $( FLEX_FIX_WARNING) ,$( PERL) $( top_srcdir) /src/tools/fix-old-flex-code.pl '$@' )
2012-10-11 12:57:04 +02:00
%.c : %.y
$( if $( BISON_CHECK_CMD) ,$( BISON_CHECK_CMD) )
$( BISON) $( BISONFLAGS) -o $@ $<
2009-02-19 11:32:30 +01:00
%.i : %.c
$( CPP) $( CPPFLAGS) -o $@ $<
2001-09-18 01:00:27 +02:00
%.gz : %
2009-11-03 22:28:10 +01:00
$( GZIP) --best -c $< >$@
2001-09-18 01:00:27 +02:00
%.bz2 : %
2009-11-03 22:28:10 +01:00
$( BZIP2) -c $< >$@
2000-07-19 18:30:27 +02:00
2012-02-02 19:24:38 +01:00
# Direct builds of foo.c -> foo are disabled to avoid generating
# *.dSYM junk on Macs. All builds should normally go through the
# foo.c -> foo.o -> foo steps. This also ensures that dependency
# tracking (see below) is used.
% : %.c
Ensure link commands list *.o files before LDFLAGS.
It's important for link commands to list *.o input files before -l
switches for libraries, as library code may not get pulled into the link
unless referenced by an earlier command-line entry. This is certainly
necessary for static libraries (.a style). Apparently on some platforms
it is also necessary for shared libraries, as reported by Donald Dong.
We often put -l switches for within-tree libraries into LDFLAGS, meaning
that link commands that list *.o files after LDFLAGS are hazardous.
Most of our link commands got this right, but a few did not. In
particular, places that relied on gmake's default implicit link rule
failed, because that puts LDFLAGS first. Fix that by overriding the
built-in rule with our own. The implicit link rules in
src/makefiles/Makefile.* for single-.o-file shared libraries mostly
got this wrong too, so fix them. I also changed the link rules for the
backend and a couple of other places for consistency, even though they
are not (currently) at risk because they aren't adding any -l switches
to LDFLAGS.
Arguably, the real problem here is that we're abusing LDFLAGS by
putting -l switches in it and we should stop doing that. But changing
that would be quite invasive, so I'm not eager to do so.
Perhaps this is a candidate for back-patching, but so far it seems
that problems can only be exhibited in test code we don't normally
build, and at least some of the problems are new in HEAD anyway.
So I'll refrain for now.
Donald Dong and Tom Lane
Discussion: https://postgr.es/m/CAKABAquXn-BF-vBeRZxhzvPyfMqgGuc74p8BmQZyCFDpyROBJQ@mail.gmail.com
2019-01-02 19:57:42 +01:00
# Replace gmake's default rule for linking a single .o file to produce an
# executable. The main point here is to put LDFLAGS after the .o file,
# since we put -l switches into LDFLAGS and those are order-sensitive.
# In addition, include CFLAGS and LDFLAGS_EX per project conventions.
% : %.o
2019-01-05 01:12:22 +01:00
$( CC) $( CFLAGS) $^ $( LDFLAGS) $( LDFLAGS_EX) $( LIBS) -o $@ $( X)
Ensure link commands list *.o files before LDFLAGS.
It's important for link commands to list *.o input files before -l
switches for libraries, as library code may not get pulled into the link
unless referenced by an earlier command-line entry. This is certainly
necessary for static libraries (.a style). Apparently on some platforms
it is also necessary for shared libraries, as reported by Donald Dong.
We often put -l switches for within-tree libraries into LDFLAGS, meaning
that link commands that list *.o files after LDFLAGS are hazardous.
Most of our link commands got this right, but a few did not. In
particular, places that relied on gmake's default implicit link rule
failed, because that puts LDFLAGS first. Fix that by overriding the
built-in rule with our own. The implicit link rules in
src/makefiles/Makefile.* for single-.o-file shared libraries mostly
got this wrong too, so fix them. I also changed the link rules for the
backend and a couple of other places for consistency, even though they
are not (currently) at risk because they aren't adding any -l switches
to LDFLAGS.
Arguably, the real problem here is that we're abusing LDFLAGS by
putting -l switches in it and we should stop doing that. But changing
that would be quite invasive, so I'm not eager to do so.
Perhaps this is a candidate for back-patching, but so far it seems
that problems can only be exhibited in test code we don't normally
build, and at least some of the problems are new in HEAD anyway.
So I'll refrain for now.
Donald Dong and Tom Lane
Discussion: https://postgr.es/m/CAKABAquXn-BF-vBeRZxhzvPyfMqgGuc74p8BmQZyCFDpyROBJQ@mail.gmail.com
2019-01-02 19:57:42 +01:00
2004-07-30 14:26:40 +02:00
i f n d e f P G X S
2000-07-19 18:30:27 +02:00
# Remake Makefile.global from Makefile.global.in if the latter
# changed. In order to trigger this rule, the including file must
# write `include $(top_builddir)/src/Makefile.global', not some
# shortcut thereof.
2000-07-16 16:50:44 +02:00
$(top_builddir)/src/Makefile.global : $( top_srcdir ) /src /Makefile .global .in $( top_builddir ) /config .status
2002-03-29 18:32:55 +01:00
cd $( top_builddir) && ./config.status src/Makefile.global
2000-07-16 16:50:44 +02:00
2001-08-24 16:07:50 +02:00
# Remake pg_config.h from pg_config.h.in if the latter changed.
# config.status will not change the timestamp on pg_config.h if it
2000-07-19 18:30:27 +02:00
# doesn't change, so as to avoid recompiling the entire tree
2000-12-29 21:39:09 +01:00
# unnecessarily. Therefore we make config.status update a timestamp file
2012-04-24 04:43:09 +02:00
# stamp-h every time it runs, so that we don't trigger this rule every time.
# (We do trigger the null rule for stamp-h to pg_config.h every time; so it's
2012-05-07 20:28:38 +02:00
# important for that rule to be empty!)
2000-07-19 18:30:27 +02:00
#
# Of course you need to turn on dependency tracking to get any
2001-08-24 16:07:50 +02:00
# dependencies on pg_config.h.
2012-05-07 20:28:38 +02:00
$(top_builddir)/src/include/pg_config.h : $( top_builddir ) /src /include /stamp -h ;
2000-12-29 21:39:09 +01:00
2001-08-24 16:07:50 +02:00
$(top_builddir)/src/include/stamp-h : $( top_srcdir ) /src /include /pg_config .h .in $( top_builddir ) /config .status
2002-03-29 18:32:55 +01:00
cd $( top_builddir) && ./config.status src/include/pg_config.h
2000-07-19 18:30:27 +02:00
2012-10-08 03:52:07 +02:00
# Also remake pg_config_ext.h from pg_config_ext.h.in, same logic as above.
$(top_builddir)/src/include/pg_config_ext.h : $( top_builddir ) /src /include /stamp -ext -h ;
$(top_builddir)/src/include/stamp-ext-h : $( top_srcdir ) /src /include /pg_config_ext .h .in $( top_builddir ) /config .status
cd $( top_builddir) && ./config.status src/include/pg_config_ext.h
2010-11-23 21:27:50 +01:00
# Also remake ecpg_config.h from ecpg_config.h.in if the latter changed, same
2009-01-22 23:27:13 +01:00
# logic as above.
2012-05-07 20:28:38 +02:00
$(top_builddir)/src/interfaces/ecpg/include/ecpg_config.h : $( top_builddir ) /src /interfaces /ecpg /include /stamp -h ;
2009-01-22 23:27:13 +01:00
$( top_builddir) /src/interfaces/ecpg/include/stamp-h: $( top_builddir) /src/interfaces/ecpg/include/ecpg_config.h.in $( top_builddir) /config.status
2006-08-23 14:01:53 +02:00
cd $( top_builddir) && ./config.status src/interfaces/ecpg/include/ecpg_config.h
2000-07-19 18:30:27 +02:00
# When configure changes, rerun configure with the same options as
# last time. To change configure, you need to run autoconf manually.
2000-07-16 16:50:44 +02:00
$(top_builddir)/config.status : $( top_srcdir ) /configure
cd $( top_builddir) && ./config.status --recheck
2004-07-30 14:26:40 +02:00
e n d i f # not PGXS
2000-07-16 16:50:44 +02:00
2002-04-10 18:45:25 +02:00
install-strip :
2012-06-27 12:40:51 +02:00
# install-strip always uses install-sh, so that strip options can be
# passed.
$( MAKE) use_install_sh = yes \
INSTALL_PROGRAM_ENV = " STRIPPROG=' $( STRIP) ' " \
2002-04-10 18:45:25 +02:00
INSTALL_STLIB_ENV = " STRIPPROG=' $( STRIP_STATIC_LIB) ' " \
INSTALL_SHLIB_ENV = " STRIPPROG=' $( STRIP_SHARED_LIB) ' " \
INSTALL_STRIP_FLAG = -s \
install
2010-11-12 21:15:16 +01:00
##########################################################################
#
# Recursive make support
# ----------------------
# Instead of recursing through subdirectories with a for loop or
# repeated $(MAKE) -C whatever calls, this is a little smarter: it
# allows parallel make across directories and lets make -k and -q work
# correctly.
2022-07-23 18:12:42 +02:00
# We need the ability to export target-specific variables, which was
# added in GNU make 3.81. That also happens to be the version
# where the .FEATURES variable was introduced, so this is a simple check.
i f n d e f . F E A T U R E S
$( error GNU make 3.81 or newer is required . You are using version $ ( MAKE_VERSION ) )
2010-11-14 18:50:06 +01:00
e n d i f
2010-11-12 21:15:16 +01:00
# This function is only for internal use below. It should be called
2018-07-31 00:04:39 +02:00
# using $(eval). It will set up a target so that it recurses into a
# given subdirectory. For the tree-wide all/install/check/installcheck cases,
2018-04-09 22:42:02 +02:00
# ensure we do our one-time tasks before recursing (see targets above).
# Note that to avoid a nasty bug in make 3.80,
2022-07-23 18:12:42 +02:00
# this function was written to not use any complicated constructs (like
2010-11-15 07:00:48 +01:00
# multiple targets on a line) and also not contain any lines that expand
# to more than about 200 bytes. This is why we make it apply to just one
# subdirectory at a time, rather than to a list of subdirectories.
2010-11-12 21:15:16 +01:00
# $1: target name, e.g., all
2010-11-14 18:50:06 +01:00
# $2: subdir name
2010-11-12 21:15:16 +01:00
# $3: target to run in subdir, usually same as $1
d e f i n e _ c r e a t e _ r e c u r s i v e _ t a r g e t
2010-11-14 18:50:06 +01:00
.PHONY : $( 1) -$( 2) -recurse
$(1) : $( 1) -$( 2) -recurse
2018-07-31 00:04:39 +02:00
$(1)-$(2)-recurse : $( if $ ( filter all install check installcheck , $ ( 3) ) , submake -generated -headers ) $( if $ ( filter check , $ ( 3) ) , temp -install )
2010-11-14 18:50:06 +01:00
$$ ( MAKE) -C $( 2) $( 3)
2010-11-12 21:15:16 +01:00
e n d e f
# Note that the use of $$ on the last line above is important; we want
2010-11-14 18:50:06 +01:00
# $(MAKE) to be evaluated when the rule is run, not when the $(eval) is run
# to create the rule. This is necessary to get make -q working.
2010-11-12 21:15:16 +01:00
2010-11-14 18:50:06 +01:00
# Call this function in a makefile that needs to recurse into subdirectories.
# In the normal case all arguments can be defaulted.
2010-11-12 21:15:16 +01:00
# $1: targets to make recursive (defaults to list of standard targets)
# $2: list of subdirs (defaults to SUBDIRS variable)
2010-11-14 18:50:06 +01:00
# $3: target to run in subdir (defaults to current element of $1)
recurse = $( foreach target,$( if $1 ,$1 ,$( standard_targets) ) ,$( foreach subdir,$( if $2 ,$2 ,$( SUBDIRS) ) ,$( eval $( call _create_recursive_target,$( target) ,$( subdir) ,$( if $3 ,$3 ,$( target) ) ) ) ) )
2010-11-12 21:15:16 +01:00
2011-07-03 19:55:02 +02:00
# If a makefile's list of SUBDIRS varies depending on configuration, then
# any subdirectories excluded from SUBDIRS should instead be added to
# ALWAYS_SUBDIRS, and then it must call recurse_always as well as recurse.
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 ensures that distclean, etc will apply to all subdirectories.
2011-07-03 19:55:02 +02:00
# In the normal case all arguments will be defaulted.
# $1: targets to make recursive (defaults to standard_always_targets)
# $2: list of subdirs (defaults to ALWAYS_SUBDIRS variable)
# $3: target to run in subdir (defaults to current element of $1)
recurse_always = $( foreach target,$( if $1 ,$1 ,$( standard_always_targets) ) ,$( foreach subdir,$( if $2 ,$2 ,$( ALWAYS_SUBDIRS) ) ,$( eval $( call _create_recursive_target,$( target) ,$( subdir) ,$( if $3 ,$3 ,$( target) ) ) ) ) )
2010-11-12 21:15:16 +01:00
2000-10-08 23:13:27 +02:00
##########################################################################
#
2000-07-16 16:50:44 +02:00
# Automatic dependency generation
# -------------------------------
# When we configure with --enable-depend then we override the default
# compilation rule with the magic below. While or after creating the
# actual output file we also create a dependency list for the .c file.
# Next time we invoke make we will have top-notch information about
# whether this file needs to be updated. The dependency files are kept
# in the .deps subdirectory of each directory.
autodepend = @autodepend@
2000-09-08 20:29:28 +02:00
i f e q ( $( autodepend ) , y e s )
2000-07-16 16:50:44 +02:00
2000-10-29 17:13:28 +01:00
i f n d e f C O M P I L E . c
COMPILE.c = $( CC) $( CFLAGS) $( CPPFLAGS) -c
e n d i f
2018-03-20 23:41:15 +01:00
i f n d e f C O M P I L E . c c
COMPILE.cc = $( CXX) $( CXXFLAGS) $( CPPFLAGS) -c
e n d i f
2000-07-16 16:50:44 +02:00
DEPDIR = .deps
2000-10-29 17:13:28 +01:00
2000-07-16 16:50:44 +02:00
i f e q ( $( GCC ) , y e s )
# GCC allows us to create object and dependency file in one invocation.
%.o : %.c
2006-07-22 00:37:37 +02:00
@if test ! -d $( DEPDIR) ; then mkdir -p $( DEPDIR) ; fi
$( COMPILE.c) -o $@ $< -MMD -MP -MF $( DEPDIR) /$( *F) .Po
2000-07-16 16:50:44 +02:00
2018-03-20 23:41:15 +01:00
%.o : %.cpp
@if test ! -d $( DEPDIR) ; then mkdir -p $( DEPDIR) ; fi
$( COMPILE.cc) -o $@ $< -MMD -MP -MF $( DEPDIR) /$( *F) .Po
2000-07-16 16:50:44 +02:00
e n d i f # GCC
# Include all the dependency files generated for the current
2013-04-13 04:45:51 +02:00
# directory. Note that make would complain if include was called with
# no arguments.
Po_files := $( wildcard $( DEPDIR) /*.Po)
i f n e q ( , $( Po_files ) )
i n c l u d e $( Po_files )
e n d i f
2000-07-16 16:50:44 +02:00
# hook for clean-up
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
clean distclean : clean -deps
2000-07-16 16:50:44 +02:00
.PHONY : clean -deps
clean-deps :
2006-07-22 00:37:37 +02:00
@rm -rf $( DEPDIR)
2000-07-16 16:50:44 +02:00
e n d i f # autodepend
2001-06-02 20:25:18 +02:00
##########################################################################
#
# Native language support
i f e q ( $( enable_nls ) , y e s )
i f n e q ( , $( wildcard $ ( srcdir ) /nls .mk ) )
i n c l u d e $( top_srcdir ) / s r c / n l s - g l o b a l . m k
e n d i f # nls.mk
e n d i f # enable_nls
2008-09-05 14:11:18 +02:00
##########################################################################
#
# Coverage
2008-10-03 17:35:17 +02:00
# Explanation of involved files:
# foo.c source file
# foo.o object file
# foo.gcno gcov graph (a.k.a. "notes") file, created at compile time
# (by gcc -ftest-coverage)
# foo.gcda gcov data file, created when the program is run (for
# programs compiled with gcc -fprofile-arcs)
# foo.c.gcov gcov output file with coverage information, created by
# gcov from foo.gcda (by "make coverage")
# foo.c.gcov.out stdout captured when foo.c.gcov is created, mildly
# interesting
2017-08-11 05:33:47 +02:00
# lcov_test.info
# lcov tracefile, built from gcda files in one directory,
2008-10-03 17:35:17 +02:00
# later collected by "make coverage-html"
2017-08-11 05:33:47 +02:00
# lcov_base.info
# tracefile for zero counters for every file, so that
# even files that are not touched by tests are counted
# for the overall coverage rate
2008-10-03 17:35:17 +02:00
2008-09-05 14:11:18 +02:00
i f e q ( $( enable_coverage ) , y e s )
2017-08-11 05:33:47 +02:00
# make coverage -- text output
2008-09-05 14:11:18 +02:00
2017-08-11 05:33:47 +02:00
local_gcda_files = $( wildcard *.gcda)
2008-09-05 14:11:18 +02:00
2017-08-11 05:33:47 +02:00
coverage : $( local_gcda_files :.gcda =.c .gcov )
2008-09-05 14:11:18 +02:00
2017-08-11 05:33:47 +02:00
%.c.gcov : %.gcda
2008-09-05 14:11:18 +02:00
$( GCOV) -b -f -p -o . $( GCOVFLAGS) $* .c >$* .c.gcov.out
2017-08-11 05:33:47 +02:00
# make coverage-html -- HTML output via lcov
2009-08-07 22:50:22 +02:00
.PHONY : coverage -html
2017-08-11 05:33:47 +02:00
coverage-html : coverage -html -stamp
2017-08-11 05:33:47 +02:00
GENHTML_FLAGS = -q --legend
2017-08-11 05:33:47 +02:00
GENHTML_TITLE = PostgreSQL $( VERSION)
2017-08-11 05:33:47 +02:00
coverage-html-stamp : lcov_base .info lcov_test .info
2009-08-07 22:50:22 +02:00
rm -rf coverage
2017-10-14 17:40:54 +02:00
$( GENHTML) $( GENHTML_FLAGS) -o coverage --title= '$(GENHTML_TITLE)' --num-spaces= 4 $( if $( filter no,$( vpath_build) ) ,--prefix= '$(abs_top_srcdir)' ) $^
2017-08-11 05:33:47 +02:00
touch $@
2017-08-11 05:33:47 +02:00
LCOV += --gcov-tool $( GCOV)
2017-08-11 05:33:47 +02:00
LCOVFLAGS = -q --no-external
2017-08-11 05:33:47 +02:00
all_gcno_files = $( shell find . -name '*.gcno' -print)
lcov_base.info : $( all_gcno_files )
2017-08-11 05:33:47 +02:00
$( LCOV) $( LCOVFLAGS) -c -i -d . -d $( srcdir) -o $@
2017-08-11 05:33:47 +02:00
2017-08-11 05:33:47 +02:00
all_gcda_files = $( shell find . -name '*.gcda' -print)
2017-08-11 05:33:47 +02:00
lcov_test.info : $( all_gcda_files )
2017-08-11 05:33:47 +02:00
$( LCOV) $( LCOVFLAGS) -c -d . -d $( srcdir) -o $@
2009-08-07 22:50:22 +02:00
2008-09-05 14:11:18 +02:00
# hook for clean-up
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
clean distclean : clean -coverage
2008-09-05 14:11:18 +02:00
.PHONY : clean -coverage
clean-coverage :
2017-08-11 05:33:47 +02:00
rm -rf coverage coverage-html-stamp
2017-08-11 05:33:47 +02:00
rm -f *.gcda *.gcno lcov*.info *.gcov .*.gcov *.gcov.out
2008-09-05 14:11:18 +02:00
# User-callable target to reset counts between test runs
coverage-clean :
rm -f ` find . -name '*.gcda' -print`
e n d i f # enable_coverage
Support for optimizing and emitting code in LLVM JIT provider.
This commit introduces the ability to actually generate code using
LLVM. In particular, this adds:
- Ability to emit code both in heavily optimized and largely
unoptimized fashion
- Batching facility to allow functions to be defined in small
increments, but optimized and emitted in executable form in larger
batches (for performance and memory efficiency)
- Type and function declaration synchronization between runtime
generated code and normal postgres code. This is critical to be able
to access struct fields etc.
- Developer oriented jit_dump_bitcode GUC, for inspecting / debugging
the generated code.
- per JitContext statistics of number of functions, time spent
generating code, optimizing, and emitting it. This will later be
employed for EXPLAIN support.
This commit doesn't yet contain any code actually generating
functions. That'll follow in later commits.
Documentation for GUCs added, and for JIT in general, will be added in
later commits.
Author: Andres Freund, with contributions by Pierre Ducroquet
Testing-By: Thomas Munro, Peter Eisentraut
Discussion: https://postgr.es/m/20170901064131.tazjxwus3k2w3ybh@alap3.anarazel.de
2018-03-22 19:05:22 +01:00
##########################################################################
#
# LLVM support
#
i f n d e f C O M P I L E . c . b c
# -Wno-ignored-attributes added so gnu_printf doesn't trigger
# warnings, when the main binary is compiled with C.
COMPILE.c.bc = $( CLANG) -Wno-ignored-attributes $( BITCODE_CFLAGS) $( CPPFLAGS) -flto= thin -emit-llvm -c
e n d i f
i f n d e f C O M P I L E . c x x . b c
COMPILE.cxx.bc = $( CLANG) -xc++ -Wno-ignored-attributes $( BITCODE_CXXFLAGS) $( CPPFLAGS) -flto= thin -emit-llvm -c
e n d i f
%.bc : %.c
$( COMPILE.c.bc) -o $@ $<
%.bc : %.cpp
$( COMPILE.cxx.bc) -o $@ $<
2018-03-28 22:19:08 +02:00
# Install LLVM bitcode module (for JITing).
#
# The arguments are:
# $(1) name of the module (e.g. an extension's name or postgres for core code)
# $(2) source objects, with .o suffix
#
# The many INSTALL_DATA invocations aren't particularly fast, it'd be
# good if we could coalesce them, but I didn't find a good way.
2018-04-28 20:45:39 +02:00
#
# Note: blank line at end of macro is necessary to let it be used in foreach
2018-04-28 20:02:57 +02:00
d e f i n e i n s t a l l _ l l v m _ m o d u l e
$( MKDIR_P ) '$(DESTDIR)${bitcodedir}/$(1)'
$( MKDIR_P ) $( sort $ ( dir $ ( addprefix '$ ( DESTDIR ) $ {bitcodedir }'/$ ( 1) /, $ ( 2) ) ) )
$( foreach obj , $ {2}, $ ( INSTALL_DATA ) $ ( patsubst %.o ,%.bc , $ ( obj ) ) '$ ( DESTDIR ) $ {bitcodedir }'/$ ( 1) /$ ( dir $ ( obj ) )
2018-03-28 22:19:08 +02:00
)
2018-04-28 20:02:57 +02:00
c d '$(DESTDIR)${bitcodedir}' & & $( LLVM_BINPATH ) / l l v m - l t o - t h i n l t o -thinlto-action = thinlink -o $( 1) .index.bc $( addprefix $( 1) /,$( patsubst %.o,%.bc, $( 2) ) )
2018-04-28 20:45:39 +02:00
2018-03-28 22:19:08 +02:00
e n d e f
# Uninstall LLVM bitcode module.
#
# The arguments are:
# $(1) name of the module (e.g. an extension's name or postgres for core code)
#
# This intentionally doesn't use the explicit installed file list,
# seems too likely to change regularly.
d e f i n e u n i n s t a l l _ l l v m _ m o d u l e
2018-04-28 20:02:57 +02:00
r m - r f '$(DESTDIR)${bitcodedir}/$(1)/'
r m - f '$(DESTDIR)${bitcodedir}/$(1).index.bc'
2018-04-28 20:45:39 +02:00
2018-03-28 22:19:08 +02:00
e n d e f
