lmi
[Top][All Lists]
Advanced

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

Re: [lmi] [lmi-commits] master 1372a42 6/7: Use '-isystem' to suppress w


From: Vadim Zeitlin
Subject: Re: [lmi] [lmi-commits] master 1372a42 6/7: Use '-isystem' to suppress warnings in third-party headers
Date: Mon, 8 Jun 2020 13:51:11 +0200

On Sun,  7 Jun 2020 18:03:29 -0400 (EDT) Greg Chicares 
<gchicares@sbcglobal.net> wrote:

GC> branch: master
GC> commit 1372a42340285f6f3604db30a371142b54261991
GC> Author: Gregory W. Chicares <gchicares@sbcglobal.net>
GC> Commit: Gregory W. Chicares <gchicares@sbcglobal.net>
GC> 
GC>     Use '-isystem' to suppress warnings in third-party headers

 Funnily enough, a commit[1] with the message

        Replace `-isystem` compile flag with `-I`

        Using `-isystem` flag causes compilation errors with GCC10.
        Replace it with `-I` flag.

was merged into another project I follow/participate in just yesterday. And
the discussion of this commit links to gcc bug[2] where one of gcc
maintainers wrote

> you shouldn't use -isystem unless you really need to change the search
> order for system directories!

and recommended using GCC diagnostic pragmas for disabling the warnings
instead. Now, AFAICS, lmi shouldn't be affected by the problem in this bug,
because it doesn't use "-isystem /usr/include", but I think it might still
be unwise to use -isystem for warning suppression if gcc developers don't
advise using it for this.

[1] https://github.com/swig/swig/commit/9da2e4f5d45e5c92f6c3383dbdf81705a251c2ca
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129

GC>     Some third-party headers elicit warnings, which '-Werror' turns into
GC>     errors. There are several ways to avoid that:
GC>     
GC>     (1) Use pragmata to suppress the warnings before including such headers,
GC>        and "pop" their suppression right after including them. That doesn't
GC>        suppress warnings stemming from macros in those headers. In theory,
GC>        each such macro expansion could be surrounded by pragmata, but that's
GC>        tedious and ugly.

 I haven't tried it, but what about defining our own macros using pragmas
around the original macro invocation, shouldn't this work?

 Regards,
VZ

Attachment: pgpJWLsE1xMML.pgp
Description: PGP signature


reply via email to

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