bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bruno Haible
Subject: Re: gcc -Wall vs. manywarnings, git checkout vs. tarball
Date: Wed, 07 Jun 2023 00:11:30 +0200

Paul Eggert wrote:
> >    * Compilations from a git checkout and compilations from a tarball
> >      behave the same way.
> 
> They can behave differently if the person checking out from git (or 
> building from a tarball) has a different environment from the person who 
> built the tarball.

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.
    There are bugs that occur only in tarballs (e.g. when a file has not
    been included in the tarball); fortunately "make distcheck" catches this.
    There are bugs that occur only in git checkouts (e.g. libtool.m4 or
    pkg.m4 that cannot be found).
    We need to support both environments. But the more similar they behave,
    the better (in order to minimize the required testing).
    Using different -Werror settings in the two cases is not good, IMO.

  * 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.

> And to some extent this problem is unavoidable in our 
> current build model: if you're building from git you need to be more of 
> an expert, and we can expect more from experts. The only question is how 
> much to expect.

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]

Bruno

[1] https://savannah.gnu.org/bugs/?62196






reply via email to

[Prev in Thread] Current Thread [Next in Thread]