bug-gnulib
[Top][All Lists]
Advanced

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

Re: clang++ 11 compilation issues


From: Jeffrey Walton
Subject: Re: clang++ 11 compilation issues
Date: Wed, 13 Jan 2021 16:04:00 -0500

On Tue, Jan 12, 2021 at 3:19 PM Bruno Haible <bruno@clisp.org> wrote:
>
> Hi Alexandre,
>
> > I'm upgrading a project that used a 8-month-old copy of gnulib to
> > today's version
>
> Since then, gnulib has improved its support for clang.
>
> > I compile with -Werror.
>
> Gnulib generally does not support -Werror on arbitrary platforms.
>
> We try to make for a warning-free compilation on glibc systems with GCC,
> as far as it is reasonable (but it does not work always, due to GCC bugs).
>
> > Testing the result with clang++ 11.0.1-2 (Debian unstable)
>
> Now, using clang with -Wall and -Werror is a recipe for failures, for sure.
>
> This is because clang has _many_ warnings, and
>
>   - Some of the warnings are of the kind "tell me when you did a certain
>     optimization". Most of the warnings in this category are not helpful.
>
>   - Some of the warnings merely enforce certain coding styles. You can
>     try to enforce your preferred coding style on your code, but enforcing
>     it on Gnulib code is a non-starter.
>
>   - Some of the warnings are contradictory.
>
> You are supposed to choose the warnings that are reasonable for your
> project. For some project of mine, I had to disable 20-40 warning options
> before I could get reasonable output.

Perhaps it would be a good idea to filter-out the options that you
don't want present for Gnulib.

If you are doing it during configure, then take the user's CFLAGS (or
CXXFLAGS) and then:

       TCFLAGS=`echo $CFLAGS | sed -e 's/-Wall//g' -e 's/-Wextra//g'
-e 's/-Werror//g'`

If you are doing it during make, then use a recipe like this for Gnulib sources:

    GL_CFLAGS := $(filter-out -Wall -Wextra -Werror% -Wunused
-Wconversion -Wp%, $(CFLAGS))
    ...
    %.o:%.c:
        $CC $(strip $CPPFLAGS $GL_CFLAGS -c) $<

That will put an end to these mailing list messages and bug reports.
You get what you want, and users get what they want.

Otherwise, this is an exercise in insanity. Users keep doing the same
thing, GNU keeps doing the same thing, but everyone expects a
different outcome. Instead of practicing inanity, engineer a fix for
the problem.

Jeff



reply via email to

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