回复: cleanup: Split long Makefile lists across lines and sort them

From: Japin Li <japinli(at)hotmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, zengman <zengman(at)halodbtech(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: 回复: cleanup: Split long Makefile lists across lines and sort them
Date: 2025-12-28 04:12:16
Message-ID: MEAPR01MB3031009A16B0DE41E75923CCB6BEA@MEAPR01MB3031.ausprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Sat, Dec 27, 2025 at 08:30:59AM +0900, Michael Paquier wrote:
> On Fri, Dec 26, 2025 at 06:30:53PM +0100, Jelte Fennema-Nio wrote:
>> > If we look at existing Makefiles, they don’t add a tailing “\” in the last line of lists, so let’s keep consistent.
>>
>> Alright, attached is one without the trailing backslash. If we want to
>> add those let's indeed do it in a dedicated patch that makes all of such
>> lists consistently use them.

Expanded that to a few more SUBDIRS noticed on the way, without the
backslash after the last item of each list, and applied the result.

We have quite a few more REGRESS lists in contrib/. Would these be
worth changing for test_decoding or pg_stat_statements at least?

I have a few questions:

1. Regarding splitting long lists: Is there an established convention or
threshold (e.g., maximum number of items per line or maximum line length)
that we should follow when deciding whether to break a list across multiple
lines?

2. I noticed that btree_gin, btree_gist, and pgcrypto also have relatively
long REGRESS lists, should we also update them?

3. Does this formatting guideline also extend to the DATA variable (for
example in contrib Makefiles), or is it mainly intended for REGRESS lists?

--
Regards,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Henson Choi 2025-12-28 04:43:54 Re: SQL Property Graph Queries (SQL/PGQ)
Previous Message Chengpeng Yan 2025-12-28 02:54:16 Re: Add a greedy join search algorithm to handle large join problems