GNU bug report logs - #20713
aclocal/tar.m4 and solaris 5.10 where `id -u` is not supported

Previous Next

Full log

View this message in rfc822 format

From: Mike Frysinger <vapier <at> gentoo.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: 20713 <at> debbugs.gnu.org
Subject: bug#20713: aclocal/tar.m4 and solaris 5.10
Date: Wed, 23 Feb 2022 00:39:38 -0500

[Message part 1 (text/plain, inline)]

On 22 Feb 2022 16:29, Karl Berry wrote:
> The "test" item, most of the way down in the "Limitations of Shell
> Builtins" node of the Autoconf manual, reports a lot of the things that
> have led to the common forms/workarounds.
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Builtins.html#Limitations-of-Builtins

thanks, this is what i was looking for.  maybe i should actually read the
autotools manuals one day instead of using them purely as references.

>     the reason your system hit this code path
> 
> I was not running make dist. I was just running configure on Solaris 5.10.
> As far as I can recall.

i'm sure that was the case (i.e. you ran configure but never dist).  but if
we can only test tools during configure, and the dist step requires results
from that probing, but we're not allowed to probe dist-specific tools during
configure, then we're in a bit of a catch-22.

i'm not aware of other parts being delayed/split based on their usage.  for
example, if i just `make && make install`, one could argue that configure
checking for deps/behaviors that only matter to `make check` are incorrect.

off the top of my head, i think Automake's `missing` tool is about the only
exception to this approach/rule, and even then, that's pretty thin -- it's
only seeing if a specific program exists, not whether it supports specific
functionality or is otherwise buggy.

>    it can be helpful when you're hacking on a system and want to pull
>    the state back out.
>     
> Personally, I would never trust make dist not to alter the state
> that it was supposedly snapshotting.

to be clear, when i said "state", i meant "the source code".  obviously i
wouldn't expect (or want) `make dist` to pick up any intermediates or build
outputs.  i'm not sure along what lines your distrust of dist flows, but i
will point out that this logic is entirely Automake's, so it would be a
little unusable if you consider `make dist` unreliable as a maintainer of
Automake :).
-mike

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.