On Mon, Apr 14, 2025 at 09:03:30PM +0100, Ramsay Jones wrote:
> 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. :)
Makes sense, it's a bigger discussion indeed. I do think it would be
reasonable to drop pre-2.0 Cygwin, and we have recently become a bit
more aggressive in dropping support for ancient OS versions. But I'm
totally fine with not doing it now.
Patrick
