bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
* Prefer AM_GNU_GETTEXT_REQUIRE_VERSION?
@ 2021-11-23 20:02 Simon Josefsson via Gnulib discussion list
  2021-12-06  1:20 ` Bruno Haible
  0 siblings, 1 reply; 2+ messages in thread
From: Simon Josefsson via Gnulib discussion list @ 2021-11-23 20:02 UTC (permalink / raw)
  To: bug-gnulib

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

Hi.  This may mostly be for Bruno, but I believe it is more relevent to
gnulib than gettext, even though it is gettext-related, and maybe others
on this list can provide feedback too.

I got a bug report that suggested using AM_GNU_GETTEXT_REQUIRE_VERSION:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999510

The suggestion boils down to:

-AM_GNU_GETTEXT_VERSION([0.19.3])
+AM_GNU_GETTEXT_REQUIRE_VERSION([0.19.8])
+AM_GNU_GETTEXT_VERSION([0.19.6])

Libidn2 (and many other packages) contains:

AM_GNU_GETTEXT([external])
AM_GNU_GETTEXT_VERSION([0.19.3])

Reading gettext NEWS suggests to me that 0.19.8 fixed something for
musl, and that this gettext fix is what is needed to build packages
using gettext on that platform.  Am I understanding correct?

If so, my usage of AM_GNU_GETTEXT_VERSION([0.19.3]) seems indeed
problematic because it leads to a too old gettext infrastructure being
pulled in.  It would be nice if my package used the latest available
gettext files during bootstrapping, so I should use this:

AM_GNU_GETTEXT_REQUIRE_VERSION([0.19.6])
AM_GNU_GETTEXT_VERSION([0.19.6])

Then assuming the person rebootstrapping libidn2 using a sufficiently
modern gettext (>=0.19.8) will get the acceptable fixes for musl.

Before fixing this, it occured to me that this seems like something that
should be generally true for any project using gettext.  Thoughts?  Why
wouldn't you want gettext to use the latest available infrastructure
files?  The situation seems similar to libtool's M4 handling.

Thus I would prefer to write a 'make syntax-check' rule to catch this,
and suggest that all packages should use AM_GNU_GETTEXT_REQUIRE_VERSION
to get latest gettext files included in them.  Thoughts?

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Prefer AM_GNU_GETTEXT_REQUIRE_VERSION?
  2021-11-23 20:02 Prefer AM_GNU_GETTEXT_REQUIRE_VERSION? Simon Josefsson via Gnulib discussion list
@ 2021-12-06  1:20 ` Bruno Haible
  0 siblings, 0 replies; 2+ messages in thread
From: Bruno Haible @ 2021-12-06  1:20 UTC (permalink / raw)
  To: bug-gnulib; +Cc: Simon Josefsson, bug-gettext

[CCing bug-gettext]
Simon Josefsson wrote in
<https://lists.gnu.org/archive/html/bug-gnulib/2021-11/msg00029.html>:

> Hi.  This may mostly be for Bruno, but I believe it is more relevent to
> gnulib than gettext, even though it is gettext-related, and maybe others
> on this list can provide feedback too.
> 
> I got a bug report that suggested using AM_GNU_GETTEXT_REQUIRE_VERSION:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999510
> 
> The suggestion boils down to:
> 
> -AM_GNU_GETTEXT_VERSION([0.19.3])
> +AM_GNU_GETTEXT_REQUIRE_VERSION([0.19.8])
> +AM_GNU_GETTEXT_VERSION([0.19.6])

I don't understand the use-case of AM_GNU_GETTEXT_REQUIRE_VERSION; and it's
only half documented (not listed in the TOC, not listed in the autoconf
macro index); therefore I cannot recommend to use it.

> Libidn2 (and many other packages) contains:
> 
> AM_GNU_GETTEXT([external])
> AM_GNU_GETTEXT_VERSION([0.19.3])
> 
> Reading gettext NEWS suggests to me that 0.19.8 fixed something for
> musl, and that this gettext fix is what is needed to build packages
> using gettext on that platform.  Am I understanding correct?

The NEWS entry says:
  - The AM_GNU_GETTEXT Autoconf macro can now detect musl-libc's
    gettext as a compatible implementation.

Since this was a change in the gettext.m4 macro (as opposed to the
runtime code), yes you need to do something in order to make your
package build well on musl systems.

I would suggest to just replace

  AM_GNU_GETTEXT_VERSION([0.19.3])

with

  AM_GNU_GETTEXT_VERSION([0.19.8])

> If so, my usage of AM_GNU_GETTEXT_VERSION([0.19.3]) seems indeed
> problematic because it leads to a too old gettext infrastructure being
> pulled in.  It would be nice if my package used the latest available
> gettext files during bootstrapping, so I should use this:
> 
> AM_GNU_GETTEXT_REQUIRE_VERSION([0.19.6])
> AM_GNU_GETTEXT_VERSION([0.19.6])

If you do this, different people who check out your repository and build
it will get different configure files - some with gettext.m4 0.19.6 (which
does not include the musl fix), some with 0.21, some with intermediate
versions. I wouldn't go down this route, because the difference between
what the different people get is hard to track down.

> Why
> wouldn't you want gettext to use the latest available infrastructure
> files?  The situation seems similar to libtool's M4 handling.

Because if e.g. you are the main developer, and another person is the
release manager, you don't want the release manager to release a source
tarball that is significantly different from what you have tested all
the time.

> Thus I would prefer to write a 'make syntax-check' rule to catch this,
> and suggest that all packages should use AM_GNU_GETTEXT_REQUIRE_VERSION
> to get latest gettext files included in them.

You are free to do so. But I would not do that. And certainly it should
not be done in Gnulib's maint.mk.

Bruno





^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-12-06  1:20 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-23 20:02 Prefer AM_GNU_GETTEXT_REQUIRE_VERSION? Simon Josefsson via Gnulib discussion list
2021-12-06  1:20 ` Bruno Haible

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).