All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] Tidy up 'make' output
Date: Wed, 18 Jun 2008 19:43:32 +0200	[thread overview]
Message-ID: <20080618174332.GD25553@thorin> (raw)
In-Reply-To: <48583933.4080208@coresystems.de>

On Wed, Jun 18, 2008 at 12:22:43AM +0200, Stefan Reinauer wrote:
> I would not consider this "hiding information". The information you see
> (CFLAGS for example) don't really change across the lines and there's
> always the chance to say V=1 to see all the compiler lines. The
> opposite: The current forest of duplicate information is really what is
> hiding the relevant information between a lot of uninteresting fuzz.
> Maybe, you guys would prefer to set V=1 as the default, so one would
> have to say V=0 to get above output? I am currently only compiling grub
> with make -s, because that is the only way to get any decently parsable
> output for finding issues in the code.

Yeah you have a point here.

> Please, please, don't use -Werror.  GRUB2 is currently hard enough to
> build and the build system is less than optimal and elegant. While I
> agree that clean code never throughs warnings, the amazing number of
> different gccs and build environments out there would make developing
> for grub2 and compiling it very hard. There are quite a number of
> warnings that do not matter because the developers simply know better
> than the compiler. -Werror will lead to ugly workarounds to suppress
> these warnings and make adoption of new tool chain versions a task from
> hell.

The problem with GRUB is that even a minor error can easily become critical
if it prevents you from booting.  Often -Werror can mean extra work just to
shut up a warning (although I wouldn't consider this a workaround, unless
there's some example I'm missing), but sometimes it can catch bugs that turn
out to be really hard to debug, like those involving memory corruption.

I think in the long run it would pay off.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)



  reply	other threads:[~2008-06-18 17:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-17 17:44 [PATCH] Tidy up 'make' output Colin D Bennett
2008-06-17 19:57 ` Pavel Roskin
2008-06-17 20:07   ` Colin D Bennett
2008-06-17 20:25     ` Pavel Roskin
2008-06-17 20:37 ` Robert Millan
2008-06-17 20:53   ` Pavel Roskin
2008-06-17 22:22   ` Stefan Reinauer
2008-06-18 17:43     ` Robert Millan [this message]
2008-06-17 22:31   ` Colin D Bennett
2008-06-18 17:46     ` Robert Millan
2008-06-18 18:02       ` Pavel Roskin
2008-06-18 22:21         ` Robert Millan

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=20080618174332.GD25553@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-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.
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.