devel/libgnuregex: Fix building after gnulib update

[arrowd]

Test Plan

poudriere testport, no runtime testing

[kevans]

thanks, that's nicer than what I was about to do after playing whack-a-mole with this path for a while.

[arrowd]

Sorry for breaking it in the first place. I have no idea how I missed it when going over gnulib dependents.

[kevans]

In D56386#1291241, @arrowd wrote:

Sorry for breaking it in the first place. I have no idea how I missed it when going over gnulib dependents.

No worries!

[junchoon_dec.sakura.ne.jp]

Confirmed built fine on poudriere. Thanks!

[junchoon_dec.sakura.ne.jp]

BTW, isn't bump of PORTVERSION or PORTREVISION needed as of codebase (in gnulib) changes?

Looking into commit history, especially of the first one at svn revision 559542, PORTREVISION seems to be preferrable.

https://svnweb.freebsd.org/ports?view=revision&revision=559542

[kevans]

In D56386#1291595, @junchoon_dec.sakura.ne.jp wrote:

BTW, isn't bump of PORTVERSION or PORTREVISION needed as of codebase (in gnulib) changes?

Looking into commit history, especially of the first one at svn revision 559542, PORTREVISION seems to be preferrable.

https://svnweb.freebsd.org/ports?view=revision&revision=559542

You don't need a PORTREVISION bump to address build failures, unless the failures weren't across the board (e.g., worked fine on x86 but not arm64) -- there wouldn't be any functional packages, so everyone will naturally try to rebuild it. The PORTVERSION here reflected the shlib version, so it's already not very meaningful (and the ABI won't have changed)- I would be inclined to leave it alone and think about the version independently of this change in particular, since it's a more general problem that we have no idea what version of gnuilb any particular libgnuregex was built against.

[junchoon_dec.sakura.ne.jp]

In D56386#1291600, @kevans wrote:

In D56386#1291595, @junchoon_dec.sakura.ne.jp wrote:

BTW, isn't bump of PORTVERSION or PORTREVISION needed as of codebase (in gnulib) changes?

Looking into commit history, especially of the first one at svn revision 559542, PORTREVISION seems to be preferrable.

https://svnweb.freebsd.org/ports?view=revision&revision=559542

You don't need a PORTREVISION bump to address build failures, unless the failures weren't across the board (e.g., worked fine on x86 but not arm64) -- there wouldn't be any functional packages, so everyone will naturally try to rebuild it. The PORTVERSION here reflected the shlib version, so it's already not very meaningful (and the ABI won't have changed)- I would be inclined to leave it alone and think about the version independently of this change in particular, since it's a more general problem that we have no idea what version of gnuilb any particular libgnuregex was built against.

What I meant was that this build breakage is caused by acutal code updates on gnulib that this port copies installed files from to build. So the bump is not for fixing build but for code updates corresponding to 20260127 at commit ports 929d989d32b56f3968371e6cd311ab9e9bd94a0d.

Note that bumps for every gnulib updates are not needed, but in case that files used for this is actually updated regardless build failures happenes or not.

[kevans]

In D56386#1291602, @junchoon_dec.sakura.ne.jp wrote:

In D56386#1291600, @kevans wrote:

In D56386#1291595, @junchoon_dec.sakura.ne.jp wrote:

BTW, isn't bump of PORTVERSION or PORTREVISION needed as of codebase (in gnulib) changes?

Looking into commit history, especially of the first one at svn revision 559542, PORTREVISION seems to be preferrable.

https://svnweb.freebsd.org/ports?view=revision&revision=559542

You don't need a PORTREVISION bump to address build failures, unless the failures weren't across the board (e.g., worked fine on x86 but not arm64) -- there wouldn't be any functional packages, so everyone will naturally try to rebuild it. The PORTVERSION here reflected the shlib version, so it's already not very meaningful (and the ABI won't have changed)- I would be inclined to leave it alone and think about the version independently of this change in particular, since it's a more general problem that we have no idea what version of gnuilb any particular libgnuregex was built against.

What I meant was that this build breakage is caused by acutal code updates on gnulib that this port copies installed files from to build. So the bump is not for fixing build but for code updates corresponding to 20260127 at commit ports 929d989d32b56f3968371e6cd311ab9e9bd94a0d.

Note that bumps for every gnulib updates are not needed, but in case that files used for this is actually updated regardless build failures happenes or not.

Yes, in a perfect world libgnuregex would have gotten a PORTREVISION bump when gnulib updated, but the update to gnulib triggers a rebuild anyways and that fails- since the port is actively failing, we don't need a revision bump at this time.