All of lore.kernel.org
 help / color / mirror / Atom feed
From: Colin D Bennett <colin@gibibit.com>
To: grub-devel@gnu.org
Cc: "Yoshinori K. Okuji" <okuji@enbug.org>
Subject: Re: [PATCH] Build system improvement
Date: Sat, 11 Apr 2009 08:29:59 -0700	[thread overview]
Message-ID: <200904110830.02945.colin@gibibit.com> (raw)
In-Reply-To: <200904111909.48927.okuji@enbug.org>

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

Yoshinori K. Okuji wrote on Saturday 11 April 2009:
> On Saturday 11 April 2009 08:25:50 phcoder wrote:
> > I don't see any stoppers to merge this patch
>
> Personally, I don't like this so much. Is it so useful?

Absolutely.  I find it tedious to scroll back through thousands of lines of 
text full of gcc command lines with lots of options etc. to find the actual 
warnings that could indicate (and usually do!) that I made an error in my 
code.  When all the lines generally have a concise and uniform appearance, it 
is visually easy to scan for warnings, compared to now where the lines printed 
are very long and often wrap onto multiple lines, obscuring warnings.

If we could build with -Werror, then it wouldn't be so hard to find the 
warnings since the build would abort...

I think there is only one warning (the “trampoline” warning) that we want to 
ignore.  All others can and should be fixed (and they may be already).

Regards,
Colin


> > Javier Martín wrote:
> > > This patch modifies several files in the build system (mainly
> > > common.rmk and genmk.rb) to reduce the general verbosity of the build
> > > process to a manageable, semi-informative level. Thus, what currently
> > > appears as "gcc" calls, several lines long each is turned into lines
> > > like:
> > >
> > > [M xfs.mod] COMPILE ../src/fs/xfs.c ->
> > > xfs_mod-fs_xfs.o
> > > [M xfs.mod] LINK xfs_mod-fs_xfs.o ->
> > > pre-xfs.o
> > > [M xfs.mod] Looking for EXPORTED SYMBOL definitions: pre-xfs.o
> > >
> > > And so on. The change also makes warning-hunting marginally easier,
> > > though not by much since the patch intentionally shows a line for
> > > nearly every process that did so previously. This behavior could be
> > > simplified further if needed - this post is more of an RFC than
> > > anything else. Also, it is by no means thorough or complete - only the
> > > most common processes have been addressed - as I'm a bit busy with
> > > exams.
> > >
> > > The patch makes the new behavior the default one, so a new make-time
> > > option is added: V (for "verbose"), which must have the value 1 in
> > > order to get the behavior, as in "make V=1"


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  parent reply	other threads:[~2009-04-11 15:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-25  2:39 [PATCH] Build system improvement Javier Martín
2009-01-25 10:34 ` Vesa Jääskeläinen
2009-01-25 13:23   ` Javier Martín
2009-01-25 16:38     ` Colin D Bennett
2009-04-10 23:25 ` phcoder
2009-04-11 10:09   ` Yoshinori K. Okuji
2009-04-11 11:55     ` phcoder
2009-04-11 15:29     ` Colin D Bennett [this message]
2009-04-12 21:24       ` Pavel Roskin
2009-04-13  1:07         ` David Miller
2009-04-13  5:03           ` Pavel Roskin
2009-04-14 14:52             ` Yoshinori K. Okuji
2009-05-03  8:29     ` Felix Zielcke
2009-07-22 12:41       ` Felix Zielcke
2009-07-22 16:14         ` Pavel Roskin
2009-07-22 16:59           ` 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=200904110830.02945.colin@gibibit.com \
    --to=colin@gibibit.com \
    --cc=grub-devel@gnu.org \
    --cc=okuji@enbug.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.