All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] A more readable build output ?
@ 2009-09-16 21:19 Thomas Petazzoni
  2009-09-17  7:10 ` Peter Korsgaard
  0 siblings, 1 reply; 4+ messages in thread
From: Thomas Petazzoni @ 2009-09-16 21:19 UTC (permalink / raw)
  To: buildroot

Hello,

Currently, Buildroot displays the full build log on the standard
output. Having the full build log is of course nice, but:

 *) It is quite scary for new users

 *) It makes it more complicated for new users to understand the
    different steps of the Buildroot build process

 *) It makes it more complicated to see the progression of the build
    process (what is it doing now ? is it almost at the end ?)

Therefore, I've prototyped a simple thing that redirects the build log
to a file (so that the full build log is not lost and can be examined
for diagnostic purposes) and only display messages like "Doing this",
"Doing that" on the standard output. The goal is to disable this
behaviour when V=1 is passed, but this isn't implemented yet.

I'm sending the prototype in an early/ugly state just to see how the
feature is received by the Buildroot community. If it's well received,
I'll finalize the development and polish the implementation.

The idea of the prototype is that the main Makefile calls itself by
redirecting the standard output and error output to a file, and then
redirect a special file descriptor (8) to the standard output. Then, a
MSG macro is provided to print the "Doing this", "Doing that" messages
both to file descriptor 8 (so they get displayed on the console) and to
the normal output (so that they get saved into the build log). Of
course, it means that many places in Buildroot must be modified to call
the MSG macro (but the Makefile.autotools.in machinery makes it easy
for a large set of packages). The MSG macro could replace the MESSAGE
macro currently defined in Makefile.autotools.in.

Here is the (ugly) prototype (alternative solutions or cleanup
improvements are welcome):

diff --git a/Makefile b/Makefile
index f2e349f..c557f02 100644
--- a/Makefile
+++ b/Makefile
@@ -32,6 +32,22 @@ noconfig_targets:=menuconfig xconfig config oldconfig randconfig \
        defconfig allyesconfig allnoconfig release tags \
        source-check help
 
+define MSG
+       @echo $(1) >&8
+       @echo "============================================="
+       @echo $(1)
+       @echo "============================================="
+endef
+
+MYSUBMAKE=cmd() { \
+  >/tmp/toto.log 2>&1 make -s INSIDE=1 -C . $$* || \
+   { echo "Build failed. See /tmp/toto.log for details." ; false; } }  8>&1; \
+  cmd
+
+ifneq ($(INSIDE),1)
+default:
+       $(MYSUBMAKE)
+endif

Then, to print a message, just do:

   $(call MSG,"Configuring Busybox")

What's your opinion about this ?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [Buildroot] A more readable build output ?
  2009-09-16 21:19 [Buildroot] A more readable build output ? Thomas Petazzoni
@ 2009-09-17  7:10 ` Peter Korsgaard
  2009-09-17  9:23   ` Will Newton
  2009-09-17 14:13   ` Thiago A. Corrêa
  0 siblings, 2 replies; 4+ messages in thread
From: Peter Korsgaard @ 2009-09-17  7:10 UTC (permalink / raw)
  To: buildroot

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> Hello,
 Thomas> Currently, Buildroot displays the full build log on the standard
 Thomas> output. Having the full build log is of course nice, but:

 Thomas>  *) It is quite scary for new users

 Thomas>  *) It makes it more complicated for new users to understand the
 Thomas>     different steps of the Buildroot build process

 Thomas>  *) It makes it more complicated to see the progression of the build
 Thomas>     process (what is it doing now ? is it almost at the end ?)

 Thomas> Therefore, I've prototyped a simple thing that redirects the
 Thomas> build log to a file (so that the full build log is not lost and
 Thomas> can be examined for diagnostic purposes) and only display
 Thomas> messages like "Doing this", "Doing that" on the standard
 Thomas> output. The goal is to disable this behaviour when V=1 is
 Thomas> passed, but this isn't implemented yet.

We basically have this already when you build with 'make -s'. It's not
quite as quiet as we could wish, and non-makefile.autotools.in packages
don't print their steps, but we could probably fix that.

We can argue about what the default should be though, as the output is
quite interesting for debugging purposes when things go wrong (your
suggestion about logging to a file is nice).

-- 
Bye, Peter Korsgaard

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Buildroot] A more readable build output ?
  2009-09-17  7:10 ` Peter Korsgaard
@ 2009-09-17  9:23   ` Will Newton
  2009-09-17 14:13   ` Thiago A. Corrêa
  1 sibling, 0 replies; 4+ messages in thread
From: Will Newton @ 2009-09-17  9:23 UTC (permalink / raw)
  To: buildroot

On Thu, Sep 17, 2009 at 8:10 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
> ?Thomas> Hello,
> ?Thomas> Currently, Buildroot displays the full build log on the standard
> ?Thomas> output. Having the full build log is of course nice, but:
>
> ?Thomas> ?*) It is quite scary for new users
>
> ?Thomas> ?*) It makes it more complicated for new users to understand the
> ?Thomas> ? ? different steps of the Buildroot build process
>
> ?Thomas> ?*) It makes it more complicated to see the progression of the build
> ?Thomas> ? ? process (what is it doing now ? is it almost at the end ?)
>
> ?Thomas> Therefore, I've prototyped a simple thing that redirects the
> ?Thomas> build log to a file (so that the full build log is not lost and
> ?Thomas> can be examined for diagnostic purposes) and only display
> ?Thomas> messages like "Doing this", "Doing that" on the standard
> ?Thomas> output. The goal is to disable this behaviour when V=1 is
> ?Thomas> passed, but this isn't implemented yet.
>
> We basically have this already when you build with 'make -s'. It's not
> quite as quiet as we could wish, and non-makefile.autotools.in packages
> don't print their steps, but we could probably fix that.
>
> We can argue about what the default should be though, as the output is
> quite interesting for debugging purposes when things go wrong (your
> suggestion about logging to a file is nice).

Yes, I would certainly like to have a log to file option, it would
save me from repeatedly typing the same redirection. I'm not sure
whether the build would be noisy enough with the other suggested
change though. For example "Building GCC" would offer very little
feedback for a long time, especially on slower build machines.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Buildroot] A more readable build output ?
  2009-09-17  7:10 ` Peter Korsgaard
  2009-09-17  9:23   ` Will Newton
@ 2009-09-17 14:13   ` Thiago A. Corrêa
  1 sibling, 0 replies; 4+ messages in thread
From: Thiago A. Corrêa @ 2009-09-17 14:13 UTC (permalink / raw)
  To: buildroot

Hi,

On Thu, Sep 17, 2009 at 4:10 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>
> We basically have this already when you build with 'make -s'. It's not
> quite as quiet as we could wish, and non-makefile.autotools.in packages
> don't print their steps, but we could probably fix that.

Given that devs knows make better than users, I think it's acceptable
to require make V=1 to enable the verbose output.
Actually, openwrt has it this way, except that they use make V=99

> We can argue about what the default should be though, as the output is
> quite interesting for debugging purposes when things go wrong (your
> suggestion about logging to a file is nice).
>

I think the log is even better than what we have currently. Quite
often, the cause of the failed build is show several lines above the
end of the build, specially when doing parallel build (make -j2)

Kind Regards,
    Thiago A. Correa

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-09-17 14:13 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-16 21:19 [Buildroot] A more readable build output ? Thomas Petazzoni
2009-09-17  7:10 ` Peter Korsgaard
2009-09-17  9:23   ` Will Newton
2009-09-17 14:13   ` Thiago A. Corrêa

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.