Use "?=" operator for a contrib makefile in documentation
Hi!
Please give notice to this discussion [0]https://github.com/eulerto/wal2json/pull/290.
I think that the Makefile should be written so that variable values,
specifically, PG_CONFIG, can be given to it from the environment rather
than the make command line. As a result, using the "?=" operator rather
than "=" to set a default value to the PG_CONFIG variable appears more
acceptable.
I'm not sure if this operator has to be changed in the main Postgres
source tree; after all, they're typically built with the kernel.
[0]: https://github.com/eulerto/wal2json/pull/290
[1]: https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-EXAMPLE
https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-EXAMPLE
--
Best regards,
Maxim Orlov.
Attachments:
v1-0001-Recommend-to-use-PG_CONFIG-from-the-environment-f.patchapplication/octet-stream; name=v1-0001-Recommend-to-use-PG_CONFIG-from-the-environment-f.patchDownload
From ca8864e393dfd9e2edce134c8d2901e942b29470 Mon Sep 17 00:00:00 2001
From: Maxim Orlov <orlovmg@gmail.com>
Date: Thu, 25 Sep 2025 16:04:36 +0300
Subject: [PATCH v1] Recommend to use PG_CONFIG from the environment for
contrib
For a basic example of creating an postgres extension, use the "?="
operator with PG_CONFIG. It allows you to obtain values from the
environment instead of the command line.
This avoids errors like:
$ PG_CONFIG=... make
make: pg_config: No such file or directory
---
doc/src/sgml/extend.sgml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/src/sgml/extend.sgml b/doc/src/sgml/extend.sgml
index 63c5ec6d1eb..ccdc45f0a68 100644
--- a/doc/src/sgml/extend.sgml
+++ b/doc/src/sgml/extend.sgml
@@ -1420,7 +1420,7 @@ relocatable = false
EXTENSION = pair
DATA = pair--1.0.sql
-PG_CONFIG = pg_config
+PG_CONFIG ?= pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
</programlisting>
@@ -1480,7 +1480,7 @@ DATA = isbn_issn--1.0.sql
DOCS = README.isbn_issn
HEADERS_isbn_issn = isbn_issn.h
-PG_CONFIG = pg_config
+PG_CONFIG ?= pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
</programlisting>
--
2.43.0
On 25.09.25 15:17, Maxim Orlov wrote:
I think that the Makefile should be written so that variable values,
specifically, PG_CONFIG, can be given to it from the environment rather
than the make command line. As a result, using the "?=" operator rather
than "=" to set a default value to the PG_CONFIG variable appears more
acceptable.
I think the current text is preferable. This allows running
make PG_CONFIG=...
so that you can pick a different PostgreSQL installation for a
particular build.
If you always want to use a particular PostgreSQL installation, then you
could alter the PATH in the environment.
I don't know that there is a use case of setting only PG_CONFIG in the
environment that is not covered by these other two approaches.
Peter Eisentraut <peter@eisentraut.org> writes:
On 25.09.25 15:17, Maxim Orlov wrote:
I think that the Makefile should be written so that variable values,
specifically, PG_CONFIG, can be given to it from the environment rather
than the make command line. As a result, using the "?=" operator rather
than "=" to set a default value to the PG_CONFIG variable appears more
acceptable.
I think the current text is preferable. This allows running
make PG_CONFIG=...
so that you can pick a different PostgreSQL installation for a
particular build.
AFAICT that would still work with ?=. Nonetheless, I agree with
Peter that we shouldn't change this advice (much less change all our
Makefiles that do it like that). The reason is that the gmake manual
advises caution in the use of this feature:
Thus, by setting the variable 'CFLAGS' in your environment, you can
cause all C compilations in most makefiles to use the compiler switches
you prefer. This is safe for variables with standard or conventional
meanings because you know that no makefile will use them for other
things.
...
Other use of variables from the environment is not recommended. It
is not wise for makefiles to depend for their functioning on environment
variables set up outside their control, since this would cause different
users to get different results from the same makefile. This is against
the whole purpose of most makefiles.
(This is in "Variables from the Environment", section 6.10 in the
gmake manual version that I have at hand.)
regards, tom lane
On 29.09.25 16:00, Tom Lane wrote:
Peter Eisentraut <peter@eisentraut.org> writes:
On 25.09.25 15:17, Maxim Orlov wrote:
I think that the Makefile should be written so that variable values,
specifically, PG_CONFIG, can be given to it from the environment rather
than the make command line. As a result, using the "?=" operator rather
than "=" to set a default value to the PG_CONFIG variable appears more
acceptable.I think the current text is preferable. This allows running
make PG_CONFIG=...
so that you can pick a different PostgreSQL installation for a
particular build.AFAICT that would still work with ?=. Nonetheless, I agree with
Peter that we shouldn't change this advice (much less change all our
Makefiles that do it like that). The reason is that the gmake manual
advises caution in the use of this feature:
Yes, that's what I meant. The current code allows the "postfix" make
syntax (make PG_CONFIG=...), but it doesn't allow environment variables
to take effect silently (which also prevents the "prefix" syntax
(PG_CONFIG=... make), but that's just the way things work).
Hello!
We use common scripts to check various PostgreSQL modules with various
PostgreSQL major versions. It is easier to set the required PG_CONFIG in
the enviroment than to change various make commands. In particular, they
are quite common if we want to build, install or run installcheck in a
specific directory. The PATH enviroment variable also works, but
PG_CONFIG is usually sufficient and we want to be sure of that.
On 2025-09-29 15:50, Peter Eisentraut wrote:
I think the current text is preferable. This allows running
make PG_CONFIG=...
so that you can pick a different PostgreSQL installation for a
particular build.If you always want to use a particular PostgreSQL installation, then
you could alter the PATH in the environment.I don't know that there is a use case of setting only PG_CONFIG in the
environment that is not covered by these other two approaches.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company