Skip to contentSkip to conversation

A more readable build output ?

Buildroot Thomas Petazzoni 4 participants 4 messages Sep 16, 2009 – Sep 17, 2009 Kbuild

lore
Share & tools
lore
#0 lore raw

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):

Makefile +16 -0
index f2e349f..c557f02 100644
@@ -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

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
#1 lore raw
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> 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).

Signature · 1 line
Bye, Peter Korsgaard
#2 lore raw
Quoted 21 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> 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.

Quoted 7 lines

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.

#3 lore raw
In reply to Peter Korsgaard

Hi,

Quoted 4 lines · Peter Korsgaard

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

Quoted 4 lines

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