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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 20 2021, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx/
>
> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux