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?
Patrick
