Re: tests fail on windows with default git settings

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Dave Page <dpage(at)pgadmin(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: tests fail on windows with default git settings
Date: 2024-07-10 11:12:25
Message-ID: 9b08e271-5ae9-4bf2-b328-9123fceb7b98@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2024-07-09 Tu 11:34 AM, Andrew Dunstan wrote:
>
>
> On 2024-07-09 Tu 9:52 AM, Dave Page wrote:
>>
>>
>> > What I suggest (see attached) is we run the diff command with
>> > --strip-trailing-cr on Windows. Then we just won't care if the
>> expected file
>> > and/or the output file has CRs.
>>
>> I was wondering about that too, but I wasn't sure we can rely on
>> that flag
>> being supported...
>>
>>
>> I have 4 different diff.exe's on my ~6 week old build VM (not
>> counting shims), all of which seem to support --strip-trailing-cr.
>> Those builds came with:
>>
>> - git
>> - VC++
>> - diffutils (installed by chocolatey)
>> - vcpkg
>>
>> I think it's reasonable to assume it'll be supported.
>>
>
> Ok, cool. So I propose to patch the test_json_parser and pg_bsd_indent
> tests to use it on Windows, later today unless there's some objection.
>
>
>

As I was looking at this I wondered if there might be anywhere else that
needed adjustment. One thing that occurred to me was that that maybe we
should replace the use of "-w" in pg_regress.c with this rather less
dangerous flag, so instead of ignoring any white space difference we
would only ignore line end differences. The use of "-w" apparently dates
back to 2009.

Thoughts?

cheers

andrew

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2024-07-10 11:17:50 Re: tests fail on windows with default git settings
Previous Message Tomas Vondra 2024-07-10 10:57:53 Re: Lock-free compaction. Why not?