Re: [PATCH] Install new autoreconf files.

Am 14.04.26 um 07:42 schrieb Kevin J. McCarthy:
> On Tue, Apr 14, 2026 at 08:07:10AM +0800, Kevin J. McCarthy wrote:
>> Here's what I plan on doing:
>>
>> 1. Fix up the trixie docker image to include autopoint.  Just for 
>> reference, I store these in the "docker-images" repository on gitlab: 
>> https://gitlab.com/muttmua/docker-images
>>
>> 2. Add "AM_GNU_GETTEXT_VERSION(0.21)" to configure.ac
>>
>> 3. Remove and gitignore files that are reported as "Copy file" by 
>> `gettextize -f --dry-run --no-changelog`
>>
>> 4. Change prepare script to "autoreconf -isvf".  I like the idea of 
>> the symlinks, since it makes it more obvious they are external files.
>>
>> Any comments?  Did I miss a step?
>
> This is going well, except for new problems with 'make distcheck'.  
> I'm not sure whether it's due to using symlinks now, or because of 
> newer files installed by autoreconf -f, but the distcheck build is now 
> taking place in deeper subdirectories that are partitioned by source 
> and _build and _install with permissions set.
>
> The problem is that various 'make check' targets are failing because 
> files don't exist inside the 'make distcheck' process. For example, 
> doc/Makefile.am validate fails because manual.xml is not found (since 
> it's an intermediate generated file that isn't included in the 
> tarball). I tried prepending with $(srcdir) and $(builddir) but 
> neither worked. So eventually I just added an "if test -f 
> ./manual.xml; then" around it.

I've seen a few lingering that I try to reproduce but where I saw 
fallbacks through lynx, elinks, ... which may have similar situations to 
those I've fixed in shellcheck and tabcheck recently, but I didn't drill 
down to see if those were just artifacts and it failed over to a tool it 
had, or if it was because the $(srcdir)/ prefixes were missing from the 
input files.

>
> But then check_sec.sh failed due to permission errors.  I changed that 
> to pass --tmpdir to mktemp.  And now, shellcheck is failing because 
> "gen_defs" doesn't exist, which we "echo" in additionally.

I think shellcheck and tabcheck are fixed and I saw you use a different 
option for mktemp to please OpenBSD.

>
> So I'm starting to wonder if these all should really be attached to the
> 'make check' target?  Any ideas?
>
That depends a bit on how thorough you want "make check" to be. I 
haven't bothered to strip that down or consider slow vs. fast tests. I 
know some projects do, for instance, e2fsprogs by default skips very 
slow self-tests.

Other than that I find a complete self-test suite AND the ability to 
build with different options and/or compilers from the same source tree 
very helpful in development (especially before you put something onto a 
CI builder), so I'd fix.

To lay that "local use case" out, I might:

autoreconf -svif

mkdir _build-gnu23 _build-clang-c23 _build-gcc-default _build-asan

(cd _build-gnu23 && ../configure CFLAGS="-std=gnu23 -pedantic -Og" && 
make check)
(cd _build-clang-c23 && ../configure CC=clang CFLAGS="-std=gnu23 
-pedantic -O2" && make check)
(cd _build-gcc-default && ../configure CC=gcc && make check)
(cd _build-sanitizer && ../configure CC=clang 
CFLAGS="-fsanitize=address,undefined -Og" && make check)

or something like that, which allows for incremental rebuilds without 
having to "make distclean" and re-running configure manually -- and for 
that, it helps to have full out-of-source-tree build support anyways.
I haven't checked how autoconf behaves for "make distcheck" if the 
source tree isn't capable.