> This is already technically possible without any changes to Automake, as
> you can just just leave out the dist-xxx options from AM_INIT_AUTOMAKE
> and then call the specific dist targets for each format directly:
>
> % ./configure
> [...]
> % make dist-bzip3
> [...]
> % make dist-lzip
> [...]
This is true. However, most still reach for `make dist` which in my
opinion should have never created a compressed archive in the first
place (i.e. between all or none, pick none) and used tar/ar as mandated
by POSIX. Then make dist-gzip dist-lzip etc. should have built
compressed tarballs. This would also fix make distcheck. But there's no
takebacks I'm afraid.
> That being said, I personally think that the current behaviour of the
> dist-XXX automake options is awful, because requiring users to have
> specific compressor programs installed just so they can run distcheck
> tests is very unfriendly (it is possible for users to work around such
> problems by overriding DIST_TARGETS and/or DIST_ARCHIVES on the make
> command line, but that is annoying).
I agree. I am only trying to improve UX on the side of developers and
end users; that something like this was possible (in general) was very
well conceivable to me - e.g. via a --flag to bootstrap that modifies
configure.ac in-place with `sed` or such.
> Have you tested that this works as expected on traditional shells which
> lack the "command" builtin, such as heirloom-sh or Solaris 10 /bin/sh?
I will look into this. Currently we don't break any existing
functionality, of course. My suspicion is that right now trying to build
on legacy platforms with AM_OPTIONAL_AUTOMAKE will fail.
I saw this wonderful snippet somewhere online, I guess that we could
graft it in:
```
find_in_path() {
case "$1" in
*/*)
[ -f "$1" ] && [ -x "$1" ] && {
echo "$1"
return 0
}
return 1
;;
esac
oldifs=$IFS
IFS=:
for dir in $PATH; do
[ "$dir" ] || dir=.
if [ -f "$dir/$1" ] && [ -x "$dir/$1" ]; then
IFS=$oldifs
echo "$dir/$1"
return 0
fi
done
IFS=$oldifs
return 1
}
```
Or, alternatively:
> Personally I don't think it is worth worrying about handling the scenario
> where tools magically go missing between running "configure" and running
> "make dist". Users can re-run configure.
I would be mostly inclined to agree, but then we break/loosen the
guarantee that I intend for AM_OPTIONAL_AUTOMAKE to provide: that
inclusion of AM_OPTIONAL_AUTOMAKE with any parameters should almost
never break a build.
--
With Valediction,
Kamila Szewczyk (https://iczelia.net)
On 5/14/26 10:10 PM, Nick Bowler wrote:
> On Thu, May 14, 2026 at 04:17:52PM +0200, Kamila Szewczyk wrote:
>> Some projects want to offer a recently-added archive format (such as
>> dist-bzip3, which entered Automake in 1.18 - bug#73795, or dist-lzip)
>> while remaining portable to systems whose installed Automake predates
>> the option, or whose maintainer host lacks the matching compressor or
>> archiver. Listing dist-bzip3 or dist-lzip in AM_INIT_AUTOMAKE on such a
>> system either fails at automake-time because the option is not
>> recognized, or at make-dist-time because the tool is not on PATH.
>
> This is already technically possible without any changes to Automake, as
> you can just just leave out the dist-xxx options from AM_INIT_AUTOMAKE
> and then call the specific dist targets for each format directly:
>
> % ./configure
> [...]
> % make dist-bzip3
> [...]
> % make dist-lzip
> [...]
>
> That being said, I personally think that the current behaviour of the
> dist-XXX automake options is awful, because requiring users to have
> specific compressor programs installed just so they can run distcheck
> tests is very unfriendly (it is possible for users to work around such
> problems by overriding DIST_TARGETS and/or DIST_ARCHIVES on the make
> command line, but that is annoying).
>
> Skipping formats for which the user lacks a corresponding compressor
> program should really be the normal behaviour of these options.
>
>> The new AM_OPTIONAL_AUTOMAKE macro covers exactly this case. It
>> sidesteps the default machinery offering more fault tolerance: at
>> configure time it AC_CHECK_PROGs each requested tool; at config.status
>> time it appends a guarded 'am--optional-dist-TOOL' rule to the generated
>> top-level Makefile and pushes that rule onto DIST_TARGETS. The recipe
>> re-probes the tool with 'command -v' before running it,
>
> Have you tested that this works as expected on traditional shells which
> lack the "command" builtin, such as heirloom-sh or Solaris 10 /bin/sh?
>
> Personally I don't think it is worth worrying about handling the scenario
> where tools magically go missing between running "configure" and running
> "make dist". Users can re-run configure.
>
> Cheers,
> Nick
