2010-09-20 22:08:53 +02:00
|
|
|
# src/nls-global.mk
|
2001-06-02 20:25:18 +02:00
|
|
|
|
|
|
|
|
# Common rules for Native Language Support (NLS)
|
|
|
|
|
#
|
|
|
|
|
# If some subdirectory of the source tree wants to provide NLS, it
|
|
|
|
|
# needs to contain a file 'nls.mk' with the following make variable
|
|
|
|
|
# assignments:
|
|
|
|
|
#
|
2011-06-26 22:38:29 +02:00
|
|
|
# CATALOG_NAME -- name of the message catalog (xxx.po); probably
|
|
|
|
|
# name of the program
|
|
|
|
|
# GETTEXT_FILES -- list of source files that contain message strings
|
|
|
|
|
# GETTEXT_TRIGGERS -- (optional) list of functions that contain
|
2001-06-02 20:25:18 +02:00
|
|
|
# translatable strings
|
2011-06-26 23:13:10 +02:00
|
|
|
# GETTEXT_FLAGS -- (optional) list of gettext --flag arguments to mark
|
|
|
|
|
# function arguments that contain C format strings
|
|
|
|
|
# (functions must be listed in TRIGGERS and FLAGS)
|
2001-06-02 20:25:18 +02:00
|
|
|
#
|
2022-07-13 07:51:43 +02:00
|
|
|
# Also, provide a text file 'po/LINGUAS' with a space-separated list
|
|
|
|
|
# of languages that are provided/supported.
|
|
|
|
|
#
|
2001-06-02 20:25:18 +02:00
|
|
|
# That's all, the rest is done here, if --enable-nls was specified.
|
|
|
|
|
#
|
|
|
|
|
# The only user-visible targets here are 'init-po', to make an initial
|
|
|
|
|
# "blank" catalog from program sources, and 'update-po', which is to
|
|
|
|
|
# be called if the messages in the program source have changed, in
|
|
|
|
|
# order to merge the changes into the existing .po files.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# existence checked by Makefile.global; otherwise we won't get here
|
|
|
|
|
include $(srcdir)/nls.mk
|
|
|
|
|
|
2022-07-13 09:15:01 +02:00
|
|
|
AVAIL_LANGUAGES := $(shell cat $(srcdir)/po/LINGUAS)
|
2022-07-13 07:51:43 +02:00
|
|
|
|
2001-06-02 20:25:18 +02:00
|
|
|
# If user specified the languages he wants in --enable-nls=LANGUAGES,
|
|
|
|
|
# filter out the rest. Else use all available ones.
|
|
|
|
|
ifdef WANTED_LANGUAGES
|
|
|
|
|
LANGUAGES = $(filter $(WANTED_LANGUAGES), $(AVAIL_LANGUAGES))
|
|
|
|
|
else
|
|
|
|
|
LANGUAGES = $(AVAIL_LANGUAGES)
|
|
|
|
|
endif
|
|
|
|
|
|
2002-08-21 22:42:27 +02:00
|
|
|
PO_FILES = $(addprefix po/, $(addsuffix .po, $(LANGUAGES)))
|
2012-03-28 20:06:45 +02:00
|
|
|
ALL_PO_FILES = $(addprefix po/, $(addsuffix .po, $(AVAIL_LANGUAGES)))
|
2002-08-21 22:42:27 +02:00
|
|
|
MO_FILES = $(addprefix po/, $(addsuffix .mo, $(LANGUAGES)))
|
2001-06-02 20:25:18 +02:00
|
|
|
|
2001-06-30 23:58:06 +02:00
|
|
|
ifdef XGETTEXT
|
2019-01-19 19:06:35 +01:00
|
|
|
XGETTEXT += -ctranslator --copyright-holder='PostgreSQL Global Development Group' --msgid-bugs-address=pgsql-bugs@lists.postgresql.org --no-wrap --sort-by-file --package-name='$(CATALOG_NAME) (PostgreSQL)' --package-version='$(MAJORVERSION)'
|
2012-04-05 20:22:15 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifdef MSGMERGE
|
2012-12-14 05:12:12 +01:00
|
|
|
MSGMERGE += --no-wrap --previous --sort-by-file
|
2001-06-30 23:58:06 +02:00
|
|
|
endif
|
2001-06-02 20:25:18 +02:00
|
|
|
|
2011-06-26 22:05:30 +02:00
|
|
|
# _ is defined in c.h, so it's global
|
|
|
|
|
GETTEXT_TRIGGERS += _
|
2011-06-26 23:13:10 +02:00
|
|
|
GETTEXT_FLAGS += _:1:pass-c-format
|
2011-06-26 22:05:30 +02:00
|
|
|
|
2001-06-02 20:25:18 +02:00
|
|
|
|
2011-06-26 22:50:21 +02:00
|
|
|
# common settings that apply to backend and all backend modules
|
|
|
|
|
BACKEND_COMMON_GETTEXT_TRIGGERS = \
|
2019-09-23 09:04:20 +02:00
|
|
|
$(FRONTEND_COMMON_GETTEXT_TRIGGERS) \
|
2011-06-26 22:50:21 +02:00
|
|
|
errmsg errmsg_plural:1,2 \
|
|
|
|
|
errdetail errdetail_log errdetail_plural:1,2 \
|
2021-03-31 09:15:51 +02:00
|
|
|
errhint errhint_plural:1,2 \
|
Setup error context callback for transaction lock waits
With this in place, a session blocking behind another one because of
tuple locks will get a context line mentioning the relation name, tuple
TID, and operation being done on tuple. For example:
LOG: process 11367 still waiting for ShareLock on transaction 717 after 1000.108 ms
DETAIL: Process holding the lock: 11366. Wait queue: 11367.
CONTEXT: while updating tuple (0,2) in relation "foo"
STATEMENT: UPDATE foo SET value = 3;
Most usefully, the new line is displayed by log entries due to
log_lock_waits, although of course it will be printed by any other log
message as well.
Author: Christian Kruse, some tweaks by Álvaro Herrera
Reviewed-by: Amit Kapila, Andres Freund, Tom Lane, Robert Haas
2014-03-19 19:10:36 +01:00
|
|
|
errcontext \
|
|
|
|
|
XactLockTableWait:4 \
|
|
|
|
|
MultiXactIdWait:6 \
|
|
|
|
|
ConditionalMultiXactIdWait:6
|
2011-06-26 23:13:10 +02:00
|
|
|
BACKEND_COMMON_GETTEXT_FLAGS = \
|
2019-09-23 09:04:20 +02:00
|
|
|
$(FRONTEND_COMMON_GETTEXT_FLAGS) \
|
2011-06-26 23:13:10 +02:00
|
|
|
errmsg:1:c-format errmsg_plural:1:c-format errmsg_plural:2:c-format \
|
|
|
|
|
errdetail:1:c-format errdetail_log:1:c-format errdetail_plural:1:c-format errdetail_plural:2:c-format \
|
2021-03-31 09:15:51 +02:00
|
|
|
errhint:1:c-format errhint_plural:1:c-format errhint_plural:2:c-format \
|
2011-06-26 23:13:10 +02:00
|
|
|
errcontext:1:c-format
|
2011-06-26 22:50:21 +02:00
|
|
|
|
2019-05-14 20:19:49 +02:00
|
|
|
FRONTEND_COMMON_GETTEXT_FILES = $(top_srcdir)/src/common/logging.c
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
|
|
|
|
|
FRONTEND_COMMON_GETTEXT_TRIGGERS = \
|
2022-04-08 20:55:14 +02:00
|
|
|
pg_log_error pg_log_error_detail pg_log_error_hint \
|
|
|
|
|
pg_log_warning pg_log_warning_detail pg_log_warning_hint \
|
|
|
|
|
pg_log_info pg_log_info_detail pg_log_info_hint \
|
|
|
|
|
pg_fatal pg_log_generic:3 pg_log_generic_v:3
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
|
|
|
|
|
FRONTEND_COMMON_GETTEXT_FLAGS = \
|
2022-04-08 20:55:14 +02:00
|
|
|
pg_log_error:1:c-format pg_log_error_detail:1:c-format pg_log_error_hint:1:c-format \
|
|
|
|
|
pg_log_warning:1:c-format pg_log_warning_detail:1:c-format pg_log_warning_hint:1:c-format \
|
|
|
|
|
pg_log_info:1:c-format pg_log_info_detail:1:c-format pg_log_info_hint:1:c-format \
|
|
|
|
|
pg_fatal:1:c-format pg_log_generic:3:c-format pg_log_generic_v:3:c-format
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
|
2011-06-26 22:50:21 +02:00
|
|
|
|
2001-06-02 20:25:18 +02:00
|
|
|
all-po: $(MO_FILES)
|
|
|
|
|
|
|
|
|
|
%.mo: %.po
|
2013-09-11 20:34:28 +02:00
|
|
|
$(MSGFMT) $(MSGFMT_FLAGS) -o $@ $<
|
2001-06-02 20:25:18 +02:00
|
|
|
|
|
|
|
|
ifeq ($(word 1,$(GETTEXT_FILES)),+)
|
2009-01-15 10:01:24 +01:00
|
|
|
po/$(CATALOG_NAME).pot: $(word 2, $(GETTEXT_FILES)) $(MAKEFILE_LIST)
|
2010-10-14 21:15:46 +02:00
|
|
|
ifdef XGETTEXT
|
2016-06-08 00:55:18 +02:00
|
|
|
$(XGETTEXT) -D $(srcdir) -D . -n $(addprefix -k, $(GETTEXT_TRIGGERS)) $(addprefix --flag=, $(GETTEXT_FLAGS)) -f $<
|
2001-06-02 20:25:18 +02:00
|
|
|
else
|
2010-10-14 21:15:46 +02:00
|
|
|
@echo "You don't have 'xgettext'."; exit 1
|
|
|
|
|
endif
|
|
|
|
|
else # GETTEXT_FILES
|
2009-01-15 10:01:24 +01:00
|
|
|
po/$(CATALOG_NAME).pot: $(GETTEXT_FILES) $(MAKEFILE_LIST)
|
2001-07-15 13:43:55 +02:00
|
|
|
# Change to srcdir explicitly, don't rely on $^. That way we get
|
|
|
|
|
# consistent #: file references in the po files.
|
2010-10-14 21:15:46 +02:00
|
|
|
ifdef XGETTEXT
|
2016-06-08 00:55:18 +02:00
|
|
|
$(XGETTEXT) -D $(srcdir) -D . -n $(addprefix -k, $(GETTEXT_TRIGGERS)) $(addprefix --flag=, $(GETTEXT_FLAGS)) $(GETTEXT_FILES)
|
2010-10-14 21:15:46 +02:00
|
|
|
else
|
|
|
|
|
@echo "You don't have 'xgettext'."; exit 1
|
2001-06-02 20:25:18 +02:00
|
|
|
endif
|
2010-10-14 21:15:46 +02:00
|
|
|
endif # GETTEXT_FILES
|
2009-08-27 00:24:44 +02:00
|
|
|
@$(MKDIR_P) $(dir $@)
|
2009-01-02 16:15:42 +01:00
|
|
|
sed -e '1,18 { s/SOME DESCRIPTIVE TITLE./LANGUAGE message translation file for $(CATALOG_NAME)/;s/PACKAGE/PostgreSQL/g;s/VERSION/$(MAJORVERSION)/g;s/YEAR/'`date +%Y`'/g; }' messages.po >$@
|
|
|
|
|
rm messages.po
|
2001-06-02 20:25:18 +02:00
|
|
|
|
|
|
|
|
|
2012-04-24 04:43:09 +02:00
|
|
|
# catalog name extensions must match behavior of PG_TEXTDOMAIN() in c.h
|
2001-06-02 20:25:18 +02:00
|
|
|
install-po: all-po installdirs-po
|
2002-09-03 00:19:42 +02:00
|
|
|
ifneq (,$(LANGUAGES))
|
2001-06-02 20:25:18 +02:00
|
|
|
for lang in $(LANGUAGES); do \
|
2008-12-11 08:34:09 +01:00
|
|
|
$(INSTALL_DATA) po/$$lang.mo '$(DESTDIR)$(localedir)'/$$lang/LC_MESSAGES/$(CATALOG_NAME)$(SO_MAJOR_VERSION)-$(MAJORVERSION).mo || exit 1; \
|
2001-06-02 20:25:18 +02:00
|
|
|
done
|
2002-09-03 00:19:42 +02:00
|
|
|
endif
|
2001-06-02 20:25:18 +02:00
|
|
|
|
|
|
|
|
installdirs-po:
|
2010-05-13 16:35:28 +02:00
|
|
|
$(if $(LANGUAGES),$(MKDIR_P) $(foreach lang, $(LANGUAGES), '$(DESTDIR)$(localedir)'/$(lang)/LC_MESSAGES),:)
|
2001-06-02 20:25:18 +02:00
|
|
|
|
|
|
|
|
uninstall-po:
|
2010-05-13 16:35:28 +02:00
|
|
|
$(if $(LANGUAGES),rm -f $(foreach lang, $(LANGUAGES), '$(DESTDIR)$(localedir)'/$(lang)/LC_MESSAGES/$(CATALOG_NAME)$(SO_MAJOR_VERSION)-$(MAJORVERSION).mo),:)
|
2001-06-02 20:25:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
clean-po:
|
2008-05-17 22:24:05 +02:00
|
|
|
$(if $(MO_FILES),rm -f $(MO_FILES))
|
2009-01-09 11:54:08 +01:00
|
|
|
@$(if $(wildcard po/*.po.new),rm -f po/*.po.new)
|
2003-09-15 00:40:38 +02:00
|
|
|
rm -f po/$(CATALOG_NAME).pot
|
2001-06-02 20:25:18 +02:00
|
|
|
|
|
|
|
|
|
2003-09-15 00:40:38 +02:00
|
|
|
init-po: po/$(CATALOG_NAME).pot
|
2001-06-02 20:25:18 +02:00
|
|
|
|
|
|
|
|
|
2009-01-09 11:54:08 +01:00
|
|
|
# For performance reasons, only calculate these when the user actually
|
|
|
|
|
# requested update-po or a specific file.
|
|
|
|
|
ifneq (,$(filter update-po %.po.new,$(MAKECMDGOALS)))
|
2011-12-27 19:22:51 +01:00
|
|
|
ALL_LANGUAGES := $(shell find $(top_srcdir) -name '*.po' -print | sed 's,^.*/\([^/]*\).po$$,\1,' | LC_ALL=C sort -u)
|
|
|
|
|
all_compendia := $(shell find $(top_srcdir) -name '*.po' -print | LC_ALL=C sort)
|
2001-06-02 20:25:18 +02:00
|
|
|
else
|
2009-01-09 11:54:08 +01:00
|
|
|
ALL_LANGUAGES = $(AVAIL_LANGUAGES)
|
|
|
|
|
all_compendia = FORCE
|
|
|
|
|
FORCE:
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifdef WANTED_LANGUAGES
|
|
|
|
|
ALL_LANGUAGES := $(filter $(WANTED_LANGUAGES), $(ALL_LANGUAGES))
|
2001-06-02 20:25:18 +02:00
|
|
|
endif
|
|
|
|
|
|
2009-01-09 11:54:08 +01:00
|
|
|
update-po: $(ALL_LANGUAGES:%=po/%.po.new)
|
|
|
|
|
|
|
|
|
|
$(AVAIL_LANGUAGES:%=po/%.po.new): po/%.po.new: po/%.po po/$(CATALOG_NAME).pot $(all_compendia)
|
2012-04-02 01:58:37 +02:00
|
|
|
$(MSGMERGE) --lang=$* $(word 1, $^) $(word 2,$^) -o $@ $(addprefix --compendium=,$(filter %/$*.po,$(wordlist 3,$(words $^),$^)))
|
2009-01-09 11:54:08 +01:00
|
|
|
|
2009-01-20 10:58:50 +01:00
|
|
|
# For languages not yet available, merge against oneself, to pick
|
|
|
|
|
# up translations from the compendia. (Merging against /dev/null
|
|
|
|
|
# doesn't work so well; it inserts the headers from the first-named
|
|
|
|
|
# compendium.)
|
2009-01-09 11:54:08 +01:00
|
|
|
po/%.po.new: po/$(CATALOG_NAME).pot $(all_compendia)
|
2012-04-02 01:58:37 +02:00
|
|
|
$(MSGMERGE) --lang=$* $(word 1,$^) $(word 1,$^) -o $@ $(addprefix --compendium=,$(filter %/$*.po,$(wordlist 2,$(words $^),$^)))
|
2009-01-09 11:54:08 +01:00
|
|
|
|
2001-06-02 20:25:18 +02:00
|
|
|
|
|
|
|
|
all: all-po
|
|
|
|
|
install: install-po
|
|
|
|
|
installdirs: installdirs-po
|
|
|
|
|
uninstall: uninstall-po
|
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-po
|
2001-06-02 20:25:18 +02:00
|
|
|
|
|
|
|
|
.PHONY: all-po install-po installdirs-po uninstall-po clean-po \
|
2013-09-11 20:34:28 +02:00
|
|
|
init-po update-po
|