* [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.