rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/bin/initdb/Makefile

69 lines
1.9 KiB
Makefile
Raw Normal View History

Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
#-------------------------------------------------------------------------
#
Makefile cleanup for bin and pl subtrees. They should now support all the standard semantics. Also get rid of Makefile.in's on the way and instead declare all variables in Makefile.global.
2000-06-27 02:32:06 +02:00
# Makefile for src/bin/initdb
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
#
Update copyright for 2018 Backpatch-through: certain files through 9.3
2018-01-03 05:30:12 +01:00
# Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
Add copyright mentions, per Tom Lane.
2001-02-18 19:34:02 +01:00
# Portions Copyright (c) 1994, Regents of the University of California
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
#
Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
# src/bin/initdb/Makefile
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
#
#-------------------------------------------------------------------------
Add Win32 version info to client binaries. Magnus Hagander
2004-10-05 21:30:25 +02:00
PGFILEDESC = "initdb - initialize a new database cluster"
Add PGFILEDESC description to Makefiles for all /contrib executables. Add PGAPPICON to all executable makefiles.
2010-05-12 13:33:10 +02:00
PGAPPICON=win32
Makefile cleanup for bin and pl subtrees. They should now support all the standard semantics. Also get rid of Makefile.in's on the way and instead declare all variables in Makefile.global.
2000-06-27 02:32:06 +02:00
subdir = src/bin/initdb
top_builddir = ../../..
Fix relative path references so that make knowns which dependencies refer to one another. Sort out builddir vs srcdir variable namings. Remove some now obsoleted make variables.
2000-08-31 18:12:35 +02:00
include $(top_builddir)/src/Makefile.global
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
override CPPFLAGS := -DFRONTEND -I$(libpq_srcdir) -I$(top_srcdir)/src/timezone $(CPPFLAGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
Make initdb's suggested "pg_ctl start" command line more reliable. The original coding here was not nearly careful enough about quoting special characters, and it didn't get corner cases right for constructing the pg_ctl path either. Use join_path_components() and appendShellString() to do it honestly, so that the string will more likely work if blindly copied-and-pasted. While at it, teach appendShellString() not to quote strings that clearly don't need it, so that the output from initdb doesn't become uglier than it was before in typical cases where quoting is not needed. Ryan Murphy, reviewed by Michael Paquier and myself Discussion: <CAHeEsBeAe1FeBypT3E8R1ZVZU0e8xv3A-7BHg6bEOi=jZny2Uw@mail.gmail.com>
2016-08-20 21:05:25 +02:00
# note: we need libpq only because fe_utils does
Fix broken link-command-line ordering for libpgfeutils. In the frontend Makefiles that pull in libpgfeutils, we'd generally done it like this: LDFLAGS += -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport) That method is badly broken, as seen in bug #14742 from Chris Ruprecht. The -L flag for src/fe_utils ends up being placed after whatever random -L flags are in LDFLAGS already. That puts us at risk of pulling in libpgfeutils.a from some previous installation rather than the freshly built one in src/fe_utils. Also, the lack of an "override" is hazardous if someone tries to specify some LDFLAGS on the make command line. The correct way to do it is like this: override LDFLAGS := -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport) $(LDFLAGS) so that libpgfeutils, along with libpq, libpgport, and libpgcommon, are guaranteed to be pulled in from the build tree and not from any referenced system directory, because their -L flags will appear first. In some places we'd been even lazier and done it like this: LDFLAGS += -L$(top_builddir)/src/fe_utils -lpgfeutils -lpq which is subtly wrong in an additional way: on platforms where we can't restrict the symbols exported by libpq.so, it allows libpgfeutils to latch onto libpgport and libpgcommon symbols from libpq.so, rather than directly from those static libraries as intended. This carries hazards like those explained in the comments for the libpq_pgport macro. In addition to fixing the broken libpgfeutils usages, I tried to standardize on using $(libpq_pgport) like so: override LDFLAGS := $(libpq_pgport) $(LDFLAGS) even where libpgfeutils is not in the picture. This makes no difference right now but will hopefully discourage future mistakes of the same ilk. And it's more like the way we handle CPPFLAGS in libpq-using Makefiles. In passing, just for consistency, make pgbench include PTHREAD_LIBS the same way everyplace else does, ie just after LIBS rather than in some random place in the command line. This might have practical effect if there are -L switches in that macro on some platform. It looks to me like the MSVC build scripts are not affected by this error, but someone more familiar with them than I might want to double check. Back-patch to 9.6 where libpgfeutils was introduced. In 9.6, the hazard this error creates is that a reinstallation might link to the prior installation's copy of libpgfeutils.a and thereby fail to absorb a minor-version bug fix. Discussion: https://postgr.es/m/20170714125106.9231.13772@wrigleys.postgresql.org
2017-07-14 18:26:53 +02:00
override LDFLAGS := -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport) $(LDFLAGS)
Make initdb's suggested "pg_ctl start" command line more reliable. The original coding here was not nearly careful enough about quoting special characters, and it didn't get corner cases right for constructing the pg_ctl path either. Use join_path_components() and appendShellString() to do it honestly, so that the string will more likely work if blindly copied-and-pasted. While at it, teach appendShellString() not to quote strings that clearly don't need it, so that the output from initdb doesn't become uglier than it was before in typical cases where quoting is not needed. Ryan Murphy, reviewed by Michael Paquier and myself Discussion: <CAHeEsBeAe1FeBypT3E8R1ZVZU0e8xv3A-7BHg6bEOi=jZny2Uw@mail.gmail.com>
2016-08-20 21:05:25 +02:00
Propagate with_system_tzdata setting into initdb build. findtimezone.c needs to know this setting too. Per Peter Eisentraut.
2011-09-13 16:58:06 +02:00
# use system timezone data?
ifneq (,$(with_system_tzdata))
override CPPFLAGS += '-DSYSTEMTZDIR="$(with_system_tzdata)"'
endif
Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
2013-03-17 17:06:42 +01:00
OBJS= initdb.o findtimezone.o localtime.o encnames.o $(WIN32RES)
Add C version of initdb, from Andrew Dunstan. This is his original version with a binary rmdir() we might need in the future. I will commit an update version with cleanups shortly.
2003-11-10 23:51:16 +01:00
Improved parallel make support Replace for loops in makefiles with proper dependencies. Parallel make can now span across directories. Also, make -k and make -q work properly. GNU make 3.80 or newer is now required.
2010-11-12 21:15:16 +01:00
all: initdb
Add C version of initdb, from Andrew Dunstan. This is his original version with a binary rmdir() we might need in the future. I will commit an update version with cleanups shortly.
2003-11-10 23:51:16 +01:00
initdb now needs submake-libpq and submake-libpgfeutils. More fallout from commit a00c58314. Pointed out by Michael Paquier.
2016-08-22 14:01:12 +02:00
initdb: $(OBJS) | submake-libpq submake-libpgport submake-libpgfeutils
Split the LDFLAGS make variable into two parts: LDFLAGS is now used for linking both executables and shared libraries, and we add on LDFLAGS_EX when linking executables or LDFLAGS_SL when linking shared libraries. This provides a significantly cleaner way of dealing with link-time switches than the former behavior. Also, make sure that the various platform-specific %.so: %.o rules incorporate LDFLAGS and LDFLAGS_SL; most of them missed that before. (I did not add these variables for the platforms that invoke $(LD) directly, however. It's not clear if we can do that safely, since for the most part we assume these variables use CC command-line syntax.) Per gripe from Aaron Swenson and subsequent investigation.
2010-07-05 20:54:38 +02:00
$(CC) $(CFLAGS) $(OBJS) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X)
Fix the inadvertent libpq ABI breakage discovered by Martin Pitt: the renumbering of encoding IDs done between 8.2 and 8.3 turns out to break 8.2 initdb and psql if they are run with an 8.3beta1 libpq.so. For the moment we can rearrange the order of enum pg_enc to keep the same number for everything except PG_JOHAB, which isn't a problem since there are no direct references to it in the 8.2 programs anyway. (This does force initdb unfortunately.) Going forward, we want to fix things so that encoding IDs can be changed without an ABI break, and this commit includes the changes needed to allow libpq's encoding IDs to be treated as fully independent of the backend's. The main issue is that libpq clients should not include pg_wchar.h or otherwise assume they know the specific values of libpq's encoding IDs, since they might encounter version skew between pg_wchar.h and the libpq.so they are using. To fix, have libpq officially export functions needed for encoding name<=>ID conversion and validity checking; it was doing this anyway unofficially. It's still the case that we can't renumber backend encoding IDs until the next bump in libpq's major version number, since doing so will break the 8.2-era client programs. However the code is now prepared to avoid this type of problem in future. Note that initdb is no longer a libpq client: we just pull in the two source files we need directly. The patch also fixes a few places that were being sloppy about checking for an unrecognized encoding name.
2007-10-13 22:18:42 +02:00
Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
2013-03-17 17:06:42 +01:00
# We used to pull in all of libpq to get encnames.c, but that
Fix the inadvertent libpq ABI breakage discovered by Martin Pitt: the renumbering of encoding IDs done between 8.2 and 8.3 turns out to break 8.2 initdb and psql if they are run with an 8.3beta1 libpq.so. For the moment we can rearrange the order of enum pg_enc to keep the same number for everything except PG_JOHAB, which isn't a problem since there are no direct references to it in the 8.2 programs anyway. (This does force initdb unfortunately.) Going forward, we want to fix things so that encoding IDs can be changed without an ABI break, and this commit includes the changes needed to allow libpq's encoding IDs to be treated as fully independent of the backend's. The main issue is that libpq clients should not include pg_wchar.h or otherwise assume they know the specific values of libpq's encoding IDs, since they might encounter version skew between pg_wchar.h and the libpq.so they are using. To fix, have libpq officially export functions needed for encoding name<=>ID conversion and validity checking; it was doing this anyway unofficially. It's still the case that we can't renumber backend encoding IDs until the next bump in libpq's major version number, since doing so will break the 8.2-era client programs. However the code is now prepared to avoid this type of problem in future. Note that initdb is no longer a libpq client: we just pull in the two source files we need directly. The patch also fixes a few places that were being sloppy about checking for an unrecognized encoding name.
2007-10-13 22:18:42 +02:00
# exposes us to risks of version skew if we link to a shared library.
# Do it the hard way, instead, so that we're statically linked.
encnames.c: % : $(top_srcdir)/src/backend/utils/mb/%
rm -f $@ && $(LN_S) $< .
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
# Likewise, pull in localtime.c from src/timezones
localtime.c: % : $(top_srcdir)/src/timezone/%
rm -f $@ && $(LN_S) $< .
Makefile cleanup for bin and pl subtrees. They should now support all the standard semantics. Also get rid of Makefile.in's on the way and instead declare all variables in Makefile.global.
2000-06-27 02:32:06 +02:00
install: all installdirs
Allow installation into directories containing spaces in the name.
2005-12-09 22:19:36 +01:00
$(INSTALL_PROGRAM) initdb$(X) '$(DESTDIR)$(bindir)/initdb$(X)'
Makefile simplification: the "bin" chapter
1996-11-11 14:41:36 +01:00
Makefile cleanup for bin and pl subtrees. They should now support all the standard semantics. Also get rid of Makefile.in's on the way and instead declare all variables in Makefile.global.
2000-06-27 02:32:06 +02:00
installdirs:
Update of install-sh, mkinstalldirs, and associated configury Update install-sh to that from Autoconf 2.63, plus our Darwin-specific changes (which I simplified a bit). install-sh is now able to install multiple files in one run, so we could simplify our makefiles sometime. install-sh also now has a -d option to create directories, so we don't need mkinstalldirs anymore. Use AC_PROG_MKDIR_P in configure.in, so we can use mkdir -p when available instead of install-sh -d. For consistency with the rest of the world, the corresponding make variable has been renamed from $(mkinstalldirs) to $(MKDIR_P).
2009-08-27 00:24:44 +02:00
$(MKDIR_P) '$(DESTDIR)$(bindir)'
Add empty "dep:" target.
1996-12-10 04:40:23 +01:00
Makefile cleanup for bin and pl subtrees. They should now support all the standard semantics. Also get rid of Makefile.in's on the way and instead declare all variables in Makefile.global.
2000-06-27 02:32:06 +02:00
uninstall:
Allow installation into directories containing spaces in the name.
2005-12-09 22:19:36 +01:00
rm -f '$(DESTDIR)$(bindir)/initdb$(X)'
Makefile cleanup for bin and pl subtrees. They should now support all the standard semantics. Also get rid of Makefile.in's on the way and instead declare all variables in Makefile.global.
2000-06-27 02:32:06 +02:00
Add maintainer-clean target.
2003-11-23 22:42:13 +01:00
clean distclean maintainer-clean:
Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
2013-03-17 17:06:42 +01:00
rm -f initdb$(X) $(OBJS) encnames.c localtime.c
Clean up temp installations after client program tests. Commit 7d0f493f19607774fdccb1a1ea06fdd96a3d9698 added infrastructure to perform tests in assorted src/bin/ subdirectories, but forgot to teach "make clean" to clean up the detritus the tests leave behind.
2014-04-25 21:40:35 +02:00
rm -rf tmp_check
Fix a number of places where reconfiguring with a different installation prefix would fail, because the new path did not get propagated to where it needed to be. Note this would fail even with --enable-depend.
2003-12-23 22:56:21 +01:00
As part of the work for making relocatable installs, I have re-factored all the code that looks for other binaries. I move FindExec into port/exec.c (and renamed it to find_my_binary()). I also added find_other_binary that looks for another binary in the same directory as the calling program, and checks the version string. The only behavior change was that initdb and pg_dump would look in the hard-coded bindir directory if it can't find the requested binary in the same directory as the caller. The new code throws an error. The old behavior seemed too error prone for version mismatches.
2004-05-11 23:57:15 +02:00
# ensure that changes in datadir propagate into object file
Fix a number of places where reconfiguring with a different installation prefix would fail, because the new path did not get propagated to where it needed to be. Note this would fail even with --enable-depend.
2003-12-23 22:56:21 +01:00
initdb.o: initdb.c $(top_builddir)/src/Makefile.global
Add TAP tests for client programs Reviewed-by: Pavel Stěhule <pavel.stehule@gmail.com> Reviewed-by: Erik Rijkers <er@xs4all.nl>
2014-04-15 03:33:46 +02:00
Fix parallel make risk with new check temp-install setup The "check" target no longer needs to depend on "all", because it now runs "install" directly, which in turn depends on "all". Doing both will cause problems with parallel make, because two builds will run next to each other. Also remove the redirection of the temp-install output into a log file. This was appropriate when this was done from within pg_regress, but now it's just a regular make run, and especially with the above changes this will now take the place of running the "all" target before the test suites. problem report by Jeff Janes, patch in part by Michael Paquier
2015-04-30 02:34:22 +02:00
check:
Add TAP tests for client programs Reviewed-by: Pavel Stěhule <pavel.stehule@gmail.com> Reviewed-by: Erik Rijkers <er@xs4all.nl>
2014-04-15 03:33:46 +02:00
$(prove_check)
installcheck:
$(prove_installcheck)