From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] Silencing the build
Date: Fri, 18 Jul 2014 22:15:37 +0200 [thread overview]
Message-ID: <20140718201537.GC3630@free.fr> (raw)
In-Reply-To: <CAHkwnC_eQxDKH=V+2U+pOMZj50y4oE2B_p_G+CAk8ZFG3jSsOw@mail.gmail.com>
Fabio, All,
On 2014-07-18 10:18 +0200, Fabio Porcedda spake thusly:
> On Thu, Jul 17, 2014 at 10:29 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > Thomas, All,
> >
> > On 2014-07-17 20:31 +0200, Thomas Petazzoni spake thusly:
> >> On Thu, 17 Jul 2014 19:40:46 +0200, Fabio Porcedda wrote:
> >>
> >> > > Hum, yes, but why? The entire build process is anyway very noisy, so is
> >> > > there really a point in silencing specifically this part? What is the
> >> > > ultimate goal you're trying to achieve here?
> >> >
> >> > My ultimate goal is to be able using the "-s" flags to silence all
> >> > parts, because sometimes i just want to build and view only ">>> *"
> >> > messages, errors, warning without anything else.
> >> >
> >> > As example the "toolchain-external" target already do that when the
> >> > "-s" option is used.
> >> >
> >> > I've silenced only this part because it was easy and it's anyway an improvement.
> >> >
> >> > Maybe i can work on silencing other parts too if the feature is desired.
> >>
> >> Ok, thanks for the explanation.
> >>
> >> I guess we need to decide whether having a fully silent build in "make
> >> -s" is a goal we should aim at. It seems like a good idea to me, but I
> >> don't have a really strong opinion about this.
> >>
> >> What do others think about this?
> >
> > Here's what I use for a silent build:
> >
> > brmake() {
> > make "${@}" \
> > |sed -r -e '/^.{4}>>>[[:space:]]+(.*).{5}$/!d; s//\1/;'
> > }
> >
> > Then calling 'brmake' instead of 'make', will get you only the >>> lines.
>
> Nice, so i'm not the only one who likes a silent build ;-)
Well, I still believe the build should be verbose by default, otherwise
we would miss a lot of important information on bug reports. The problem
is where to store the build.log in case of a silent build, so the user
can provide it.
I think the best we can do is document a simple solution (like my little
function above, for example).
> I think that a downside of this method is that even the stderr is
> filtered as well so messages like warning or errors are filtered as
> well.
No, because only stdout is filtered, there's no redirection of stderr.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2014-07-18 20:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-09 11:46 [Buildroot] [PATCH 1/2] apply-patches.sh: don't print anything when "-s" option is used Fabio Porcedda
2014-07-09 11:46 ` [Buildroot] [PATCH 2/2] package/Makefile.in: fix coding style regarding the '=' sign Fabio Porcedda
2014-07-15 19:28 ` [Buildroot] [PATCH 1/2] apply-patches.sh: don't print anything when "-s" option is used Thomas Petazzoni
2014-07-17 17:40 ` Fabio Porcedda
2014-07-17 18:31 ` [Buildroot] Silencing the build Thomas Petazzoni
2014-07-17 20:29 ` Yann E. MORIN
2014-07-18 8:18 ` Fabio Porcedda
2014-07-18 20:15 ` Yann E. MORIN [this message]
2014-07-21 16:25 ` Fabio Porcedda
2014-07-21 17:16 ` Yann E. MORIN
2014-07-21 17:26 ` [Buildroot] [PATCH 1/2] apply-patches.sh: don't print anything when "-s" option is used Yann E. MORIN
2014-07-25 16:42 ` Fabio Porcedda
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=20140718201537.GC3630@free.fr \
--to=yann.morin.1998@free.fr \
--cc=buildroot@busybox.net \
/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.