Re: gcc -Wall vs. manywarnings, git checkout vs. tarball

[Paul Eggert]

On 2023-06-06 15:11, Bruno Haible wrote:

> There are at least two problems here:
>
>    * A logic that distinguishes two types of environments (e.g. git checkout
>      vs. tarball) increases the test requirements....
>      We need to support both environments. But the more similar they behave,
>      the better (in order to minimize the required testing).

We need to test the two environments anyway, and we don't need much more 
testing if the environments diverge a bit more in this way.

As I see it the main problem with this sort of divergence is not that 
more testing is needed. It's that it's annoying when later tests find 
problems that should have been squashed by earlier tests. And in this 
particular case the annoyance is relatively small since the default git 
checkout warnings, which are tested earlier, should be a superset of the 
default tarball warnings.

Of course all bets are off if developers or builders use non-default 
options, but that's not something we necessarily need to worry about.


>    * The heuristic in coreutils, grep, gzip, sed is wrong:
>
>        gl_gcc_warnings=no
>        gl_GCC_VERSION_IFELSE([4], [6],
>                              [test -d "$srcdir"/.git \
>                               && ! test -f "$srcdir"/.tarball-version \
>                               && gl_gcc_warnings=yes])]
>
>      means that a random user who uses the git checkout will get
>      gl_gcc_warnings=yes, whereas a maintainer who happens to create a
>      .tarball-version file and never removes it will get gl_gcc_warnings=no.

That's due to the first attached patch, a 2014 patch to coreutils. The 
heuristic could be improved, and someone who's bothered by it could take 
a crack at it. It doesn't bother me because I rarely have 
.tarball-version litter.


> There are more and more random users, who are not experts and who try the
> git checkout of a GNU package, rather than the newest release. And then
> wonder, for example, why the INSTALL file suggests to run './configure'
> although no 'configure' file is present. [1]
> [1] https://savannah.gnu.org/bugs/?62196

Good point. And this is not the only reason INSTALL is out of date. I 
took a shot at fixing this by installing the second attached patch into 
Autoconf and propagating it into Gnulib. Comments welcome of course.

0001-build-be-more-specific-about-.git-repo-before-enabli.patch
Description: Text Data

autoconf-install-doc.diff
Description: Text Data