Re: [PATCH 2/2] grep/pcre2: factor out literal variable

2 messages, 2 authors, 2021-12-20 · open the first message on its own page

Re: [PATCH 2/2] grep/pcre2: factor out literal variable

From: Junio C Hamano <hidden>
Date: 2021-12-20 20:52:48

Ævar Arnfjörð Bjarmason [off-list ref] writes:
I think for this and 1/2 it would be really nice to pick up a version of
Hamza's CI changes:
https://lore.kernel.org/git/20211118084143.279174-2-someguy@effective-light.com/
Are there so many incompatible versions of pcre2 library whose usage
are subtly different that we need to protect ourselves with multiple
variants in CI from breakages?

I doubt pcre2 library was _that_ bad.

Adding a special task that builds with the minimum version we
support may not be too bad, but the library should be stable enough
to allow us to declare it sufficient to test the most common version
with the most common build options in our ordinary build job(s).

Re: [PATCH 2/2] grep/pcre2: factor out literal variable

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2021-12-20 22:07:12

On Mon, Dec 20 2021, Junio C Hamano wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
I think for this and 1/2 it would be really nice to pick up a version of
Hamza's CI changes:
https://lore.kernel.org/git/20211118084143.279174-2-someguy@effective-light.com/
Are there so many incompatible versions of pcre2 library whose usage
are subtly different that we need to protect ourselves with multiple
variants in CI from breakages?

I doubt pcre2 library was _that_ bad.
It's really not, but:

 * We have an optional >=10.34 feature we use (albeit trivial)
 * We have an optional >=10.36 feature we use (major, and directly related)
 * We might be targeting JIT or not, and the error handling isn't the same (known PCRE caveat)
 * We might be targeting a PCRE that knows about Unicode, or not
 * We use it in a mode where we might feed UTF-8 invalid data into the UTF-8 mode

Any update to the relevant code really needs to test the combination of
those, so it's a perfect target for CI to make that less tedious.
Adding a special task that builds with the minimum version we
support may not be too bad, but the library should be stable enough
to allow us to declare it sufficient to test the most common version
with the most common build options in our ordinary build job(s).
That's a nice idea, but not the reality of the situation. Unless we're
willing to bump the version requirement & insist on JIT && Unicode
support before using it.

The CI itself should be realtively cheap, and just runs the few tests
that would spot any breakages with the above.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help