On 14/04/2025 08:55, Patrick Steinhardt wrote:
> On Sun, Apr 06, 2025 at 08:38:33PM +0100, Ramsay Jones wrote:
>> Commit 92f63d2b05 ("Cygwin 1.7 needs compat/regex", 2013-07-19) set
>> the NO_REGEX build variable because the platform regex library failed
>> some of the tests (t4018 and t4034), which passed just fine with the
>> compat library.
>>
>> After some time (maybe a year or two), the platform library had been
>> updated (with an import from FreeBSD, I believe) and now passed the full
>> test-suite. This would be about the time of the v1.7 -> v2.0 transition
>> in 2015. I had a patch ready to send, but just didn't get around to
>> submitting it to the list. At some point in the interim, the official
>> cygwin git package used the autoconf build system, which sets the
>> NO_REGEX variable to use the platform regex library functions. The new
>> meson build system does likewise.
>>
>> The cygwin platform regex library, in addition to now passing the tests
>> which formerly failed, now passes an 'test_expect_failure' test in the
>> t7815-grep-binary test file. In particular, test #12 'git grep .fi a'
>> which determines that the regex pattern '.' matches a NUL character.
>> The commit f96e56733a ("grep: use REG_STARTEND for all matching if
>> available", 2010-05-22) added the test in question, but it does not
>> give any indication as to why the test was framed as an expected fail,
>> rather than a 'positive' test that the 'git grep' command fails to
>> match a NUL. Note that the previous test #11 was also originally
>> marked in that commit as a 'test_expect_failure', but was flipped to
>> an 'success' test in commit 7e36de5859 ("t/t7008-grep-binary.sh: un-TODO
>> a test that needs REG_STARTEND", 2010-08-17).
>>
>> In order to produce the same NO_REGEX configuration from autoconf, meson
>> and make, modify config.mak.uname to only set NO_REGEX for cygwin v1.7.
>> In addition, skip test t7815.12 on cygwin, by adding the !CYGWIN pre-
>> requisite to the test header, which (among other things) removes an
>> '...; please update test(s)' comment.
>
> Out of curiosity, because I really don't know any better: why do we have
> to even care about such oldish Cygwin installations from more than 10
> years ago? Wouldn't people generally update Cygwin every once in a while
> to have recent packages? Or is there a good reason why we should
> continue to support it?
Heh, as I said in response to Junio, I have a patch that removes all
of the config in the conditional, so that we would no longer support
any 'pre-v2.x' versions of cygwin[*]. I think that would be an entirely
reasonable thing to do, particularly as cygwin thinks of itself as
a 'rolling release' type distribution. ;)
However, I don't think it is my place to make that kind of decision
and I was leaving that patch until last. Hopefully, Adam will make
that call. :)
Thanks.
ATB,
Ramsay Jones
[*] Note, even *with* that config in place, I have no idea if pre-v2.x
versions would even compile!
