Re: Add "format" target to make and ninja to run pgindent and pgperltidy

On 2025-12-31 We 10:26 AM, Tom Lane wrote:
> Ashutosh Bapat<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> writes:
>> On Wed, Dec 31, 2025 at 5:06 PM Jelte Fennema-Nio<postgres(at)jeltef(dot)nl> wrote:
>>> This tries to make running formatting a lot easier for committers, but
>>> primarily for new contributors.
>> I generally like the idea. Since perltidy is not enforced regularly
>> (like pgindent), running it usually ends up modifying files which are
>> not part of the patch. So I avoid it if not necessary. Do you propose
>> to make it optional?
> The other obstacle is that not everybody will have the right version
> of perltidy installed, but using some other version will create a
> whole lot of extraneous noise.

pgperltidy actually checks the version now.

>
> On the whole I'd recommend not trying to automate the perltidy
> step yet. Cost/benefit is just not very good.

I'd kinda like to unify these universes, though. We could import the
pgperltidy logic into pgindent but disable it unless some flag were
given and the correct version of perltidy were present.

>
> On the substance of the patch: I wonder whether we could make things
> more reliable by using git metadata to figure out which .h and .c
> files to point pgindent at.
>
>

The git pre-commit hook I use operates with this set of files:

    files=$(git diff --cached --name-only --diff-filter=ACMR)

pgindent just currently looks at that set of files and ignores
everything that's not a .c or .h file.

I guess what you're wanting is a test to see if the file is in git or a
generated file? That doesn't really arise for me as I always do vpath
builds, so generated files are always elsewhere.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com