From: Andy Moreton <andrewjmoreton@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: New warnings on emacs-26 branch with gcc 8.2.0
Date: Sat, 11 Aug 2018 16:06:25 +0100 [thread overview]
Message-ID: <86zhxtq6xa.fsf@gmail.com> (raw)
In-Reply-To: 7cfe570f-2c34-c55e-05b0-34ffdc6e4ee0@cs.ucla.edu
On Mon 06 Aug 2018, Paul Eggert wrote:
> Andy Moreton wrote:
>> I was hoping you could provide more background, as you are are shown as
>> the most recent committer of almost every line of configure.ac related
>> to warnings.
>
> Yes, I adapt this stuff for Emacs. However, it sounds like the part you want
> changed comes from a part of Gnulib that I do not know as well.
>
>> Is this problem arising from use of the gnulib manywarnings module ? If
>> so, why do we use it and not the simpler gnuslib warnings module ?
>
> The warnings module would require the hand-maintained Emacs source code to
> list the exact set of warnings that it wants, which would be a pain to
> maintain as the set commonly changes after each GCC release. The manywarnings
> module maintains such a list for us, which is simpler for Emacs proper (and
> allows us to share this mutating list among several GNU projects). The Emacs
> configure.ac tailors the Gnulib list a bit, but mostly leaves it alone; this
> is simpler for Emacs than maintaining its own sort-of-copy of the list by
> hand.
Using the manywarnings module still requires emacs to add new warnings to
the nw list every time gcc is upgraded, so I don't think that is less
work.
The manywarnings list also lists every conceivable warning, including
-Wall and -Wextra (why specify so many explicitly then?) and some that
are specific to C++ (why list them at all?).
It woudl surely be simpler to use _Wall -Wextra and a limited number of
additional warnings that know to be useful, rather than checking if every
warning is supported, even if they are unused and pointless.
AndyM
next prev parent reply other threads:[~2018-08-11 15:06 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-05 16:33 New warnings on emacs-26 branch with gcc 8.2.0 Andy Moreton
2018-08-05 16:41 ` Noam Postavsky
2018-08-05 19:56 ` Paul Eggert
2018-08-05 22:23 ` Andy Moreton
2018-08-05 22:47 ` Paul Eggert
2018-08-06 8:30 ` Andy Moreton
2018-08-06 15:16 ` Eli Zaretskii
2018-08-06 15:26 ` Andy Moreton
2018-08-06 15:34 ` Eli Zaretskii
2018-08-06 18:37 ` Paul Eggert
2018-08-06 21:36 ` Andy Moreton
2018-08-06 21:58 ` Paul Eggert
2018-08-11 15:06 ` Andy Moreton [this message]
2018-08-11 19:23 ` Paul Eggert
2018-08-11 19:38 ` Andy Moreton
2018-08-11 20:13 ` Paul Eggert
2018-08-06 2:26 ` Eli Zaretskii
2018-08-06 3:16 ` Paul Eggert
2018-08-11 8:40 ` Eli Zaretskii
2018-08-11 10:41 ` Andy Moreton
2018-08-11 10:51 ` Eli Zaretskii
2018-08-11 15:02 ` Andy Moreton
2018-08-11 17:15 ` Eli Zaretskii
2018-08-11 18:13 ` Andy Moreton
2018-08-11 18:26 ` Eli Zaretskii
2018-08-11 18:36 ` Andy Moreton
2018-08-11 19:04 ` Andy Moreton
2018-08-11 19:10 ` Eli Zaretskii
2018-08-14 12:59 ` Andy Moreton
2018-08-14 21:20 ` Andy Moreton
2018-08-14 22:32 ` Paul Eggert
2018-08-17 14:33 ` Eli Zaretskii
2018-08-18 16:09 ` Bruno Haible
2018-08-18 17:19 ` Paul Eggert
2018-08-18 18:33 ` Bruno Haible
2018-08-18 18:44 ` Eli Zaretskii
2018-08-18 18:59 ` Paul Eggert
2018-08-18 19:17 ` Eli Zaretskii
2018-08-18 19:57 ` Paul Eggert
2018-08-18 18:41 ` Eli Zaretskii
2018-08-18 19:07 ` Andy Moreton
2018-08-18 21:25 ` Bruno Haible
2018-08-19 0:17 ` Bruno Haible
2018-08-19 2:44 ` Eli Zaretskii
2018-08-19 7:08 ` Yuri Khan
2018-08-19 8:40 ` Bruno Haible
2018-08-20 3:01 ` Richard Stallman
2018-08-20 8:20 ` Andy Moreton
2018-08-21 3:37 ` Richard Stallman
2018-08-21 3:43 ` Paul Eggert
2018-08-22 4:03 ` Richard Stallman
2018-08-17 14:32 ` Eli Zaretskii
2018-08-17 15:21 ` Andy Moreton
2018-08-17 19:45 ` Eli Zaretskii
2018-08-17 21:33 ` Andy Moreton
2018-08-18 6:25 ` Eli Zaretskii
2018-08-11 19:18 ` Paul Eggert
2018-08-15 15:53 ` Andy Moreton
2018-08-16 21:05 ` Paul Eggert
2018-08-17 14:34 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86zhxtq6xa.fsf@gmail.com \
--to=andrewjmoreton@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.