Re: [PATCH] Install new autoreconf files.

Matthias Andree via Mutt-dev <[email protected]>
Newsgroups gmane.mail.mutt.devel
Message-ID <[email protected]>
Am 13.04.26 um 12:21 schrieb Kevin J. McCarthy:
> On Mon, Apr 13, 2026 at 10:33:31AM +0200, Oswald Buddenhagen via 
> Mutt-dev wrote:
>> On Mon, Apr 13, 2026 at 12:44:21PM +0800, Kevin J. McCarthy wrote:
>>> The only workaround I could
>>> find was running autoreconf with '-if' to force install.
>>>
>> this is a completely normal thing to require for a build from a git. 
>> why are these .m4 files even in the repository?
>
> Hi Oswald,
>
> Historically they have been, for far longer than when I came on the 
> project.  The prepare script seems not to have been changed for 19 
> years.  I haven't seen this problem since I've been maintaining mutt, 
> so I'm a bit confused. 

Hi everyone, long time no mail to the lists from my part...


It helps to put a line "AM_GNU_GETTEXT_VERSION(0.21)" into 
configure.ac.  Reason is this is the only way to tell autopoint (which 
runs underneath autoreconf) to know what version the m4/ and po/ files 
it copies are from. It doesn't know, so it can break on any system 
that's sufficiently far away from the 0.21 files that Kevin checked into 
these folders 2021, with 
https://gitlab.com/muttmua/mutt/-/commit/ccc18061461c025ee05754d4b9e8f94db2fdb233

My routine for git checkouts is "autoreconf -isvf", or, spelled out, 
"autoreconf -install --symlink --verbose --force"; gettext on the 
maintainer's (Kevin's) system changes, autopoint needs the --force 
option to get the matching files there in case it's unspecified or 
somehow doesn't work because then autopoint has the liberty of making 
everything consistent (autoreconf passes the --force option through).

Now, the CI builder or another developer's computer may have a different 
gettext version then Kevin, and then that developer or CI job's notion 
of what gettext should be ("whatever I have locally") and what's in m4/ 
are inconsistence, and that wreaks havoc. I have seen over the years 
that some files get added to m4/, others are removed.

In fetchmail, the only package I maintain (upstream) that uses GNU 
gettext, I do not check in m4/ files, but my CI setup is also 
considerably narrower than mutt's apparently, and I test on a few Linux 
distros, FreeBSD, and occasionally OpenBSD


> When I updated to a vanilla gettext configuration with gettextize five 
> years ago, I committed the changes, as I thought the manual suggested:
>
> https://www.gnu.org/software/gettext/manual/html_node/Distributed-Development.html 
>
>
> However, if it I did something wrong, then let's talk about what needs 
> to be changed. 


The "something wrong" part can be fixed by adding one line 
AM_GNU_GETTEXT_VERSION(0.21) to configure.ac

Thas two impacts:

1. it specifies the oldest that can be on a user's computer when 
building mutt (because we set AM_GNU_GETTEXT([external]) as is advised), 
to avoid arcane errors but make the minimum version explicit, and if 
autopoint is older than 0.21, it will reject and suggest updating. Since 
autopoint runs before ./configure, --disable-nls does not help.

2. it tells developers' autopoint that the m4/ files are good, and on my 
Fedora 43 (which has gettext 0.25.1), it only wants to add 
po/Makevars.template (which is for bootstrapping things, but mutt 
already has po/Makevars, so it's of limited use -- for maintainers still 
helpful only during gettextize-based updates to see if new configuration 
items appear by diffing Makevars and the .template and look what's local 
customization and what's upstream addition).


HTH

Cheers,
Matthias
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.