Introduce ENDLIST to terminate multiline makefile lists
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t52980psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 02:03 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t52980_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t52980_1 && git checkout t52980_1Patchset v1 (message #1) is on t52980_1
Hi Hacker,
Patch [1]/messages/by-id/DF6HDGB559U5.3MPRFCWPONEAE@jeltef.nl reminded me of a technique that was used long ago in my early
C/C++ projects at Lucent Technologies (for those who still remember the
company :) ). In those projects, multi-line lists in Makefiles were always
terminated with $(ENDLIST), where ENDLIST is just a global dummy variable.
The benefits are:
* It clearly marks the end of a list.
* Adding or removing items does not require worrying about a trailing “\”.
* Changes at the end of a list do not introduce extra diff noise from
adjusting backslashes.
This is not a new invention on my part. I’m simply proposing to bring this
existing technique into the PostgreSQL source tree.
In this patch, I’ve only applied $(ENDLIST) to the Makefiles touched
by [1]/messages/by-id/DF6HDGB559U5.3MPRFCWPONEAE@jeltef.nl. If this approach is acceptable, I can follow up with a patch to
apply it more broadly.
Note that since ENDLIST is defined in Makefile.global.in, this change
requires rerunning ./configure.
[1]: /messages/by-id/DF6HDGB559U5.3MPRFCWPONEAE@jeltef.nl
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
On Mon, Dec 29, 2025 at 09:43:30AM +0800, Chao Li wrote:
Note that since ENDLIST is defined in Makefile.global.in, this change
requires rerunning ./configure.
FWIW, I don't see an advantage in this proposal, and it has the
disadvantage of more maintenance if one needs to create a new list.
The current state of things is simpler. I do get the argument about C
enums, but there is a difference between a grammar rule trick and
something allowed in a language specification.
--
Michael
On Mon, Dec 29, 2025 at 10:08 AM Michael Paquier <michael@paquier.xyz>
wrote:
On Mon, Dec 29, 2025 at 09:43:30AM +0800, Chao Li wrote:
Note that since ENDLIST is defined in Makefile.global.in, this change
requires rerunning ./configure.FWIW, I don't see an advantage in this proposal, and it has the
disadvantage of more maintenance if one needs to create a new list.
The current state of things is simpler.
For example, a list is:
```
OBJS = \
a.o \
b.o
```
Now we need to add c.o, then:
```
OBJS = \
a.o \
b.o \ <== this line needs to add tailing \
c.o <== add this new line
```
there are two lines of changes.
With the $(ENDLIST), we just add an single line:
```
OBJS = \
a.o \
b.o \
c.o \ <== only adding this new line, a single line of diff
$(ENDLIST)
```
Could you please explain what more maintenance would be?
I do get the argument about C enums, but there is a difference between a
grammar rule trick and
something allowed in a language specification.
I didn't mention C enums. How did you get that? I think I only mentioned
C/C++ projects because they used Makefile for building.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Michael Paquier <michael@paquier.xyz> writes:
On Mon, Dec 29, 2025 at 09:43:30AM +0800, Chao Li wrote:
Note that since ENDLIST is defined in Makefile.global.in, this change
requires rerunning ./configure.
FWIW, I don't see an advantage in this proposal, and it has the
disadvantage of more maintenance if one needs to create a new list.
The current state of things is simpler.
Same here. This is a new bit of notation that everyone reading our
Makefiles will need to understand, and I don't think it's worth
the extra cognitive burden.
regards, tom lane