All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH RFC] core: enable per-package log files
Date: Tue, 17 Oct 2017 21:03:54 +0200	[thread overview]
Message-ID: <20171017210354.38d89b3c@windsurf.lan> (raw)
In-Reply-To: <9955dbb8-0447-5a3d-9e78-a0f6f42e7e6c@mind.be>

Hello,

On Tue, 17 Oct 2017 16:44:04 +0200, Arnout Vandecappelle wrote:

> > Therefore, you end up in a situation where a lot of things have been
> > displayed, and then nothing happens (because foo is being built). So
> > you're wondering "what the heck is going on in here". And once "foo"
> > has finished building, everything is displayed, and you understand what
> > was going on. Perhaps this can be solved by having the message
> > displayed as part of a separate target. Or perhaps we don't need to
> > solve this problem at all?  
> 
>  I think we do need to do something about it, but it could be as simple as
> letting MESSAGE print to /dev/tty instead of stdout.

True. I had some code doing that as part of my experiments, so I could
revive this.

> 
> > Another thing is that I'd ideally want this to be done automatically by
> > Buildroot, which is something we can do as part of the
> > "make-calls-itself" in the main Makefile. Except that at this point, we
> > don't have the Buildroot configuration available, and I wanted to make
> > this conditional on some BR2_PARALLEL_BUILD=y option. Or we make
> > -Orecurse the default, but that is going to significantly change the
> > visible behavior even for people not using top-level parallel build.  
> 
>  Ah, you would make top-level parallel build a config option?

Yes, my idea was to have a BR2_PARALLEL_BUILD like we have
BR2_REPRODUCIBLE, mainly to guard the feature while it is being
developed/validated. Fully reliable top-level parallel build is not
going to arrive over night, so initially I would prefer to keep the
current behavior totally unchanged, except for users that opt-in by
enabling BR2_PARALLEL_BUILD. Once we agree that the feature is
reasonably safe, we can drop that option and make it the default.

> Isn't it enough to observe the -j in MAKEFLAGS?

Interestingly:

all:
	@echo $(MAKEFLAGS)
ifneq ($(filter -j%,$(MAKEFLAGS)),)
	@echo "BINGO"
endif

Never shows BINGO when called with "make -j2" even if the echo
$(MAKEFLAGS) does show that -j2 has been passed. Also a:

$(warning $(MAKEFLAGS))

shows an empty value.

>  I'm not convinced we want to add this option automatically, however, because it
> makes it more difficult for people who don't want it. Why not add it to
> utils/brmake, for example, and point people there in the documentation of
> top-level parallel build?

Sorry I lost you here :/

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2017-10-17 19:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-11  8:58 [Buildroot] Discussion on per-package logging Thomas Petazzoni
2017-10-11  9:05 ` Arnout Vandecappelle
2017-10-11  9:55   ` Thomas Petazzoni
2017-10-11 13:08 ` Yann E. MORIN
2017-10-11 13:19   ` Thomas Petazzoni
2017-10-11 14:10     ` Yann E. MORIN
2017-10-16 16:20 ` [Buildroot] [PATCH RFC] core: enable per-package log files Anisse Astier
2017-10-16 16:23   ` Anisse Astier
2017-10-16 16:52   ` Thomas Petazzoni
2017-10-16 21:18     ` Anisse Astier
2017-10-17  7:11       ` Thomas Petazzoni
2017-10-17 12:01         ` Arnout Vandecappelle
2017-10-17 12:11           ` Thomas Petazzoni
2017-10-17 14:44             ` Arnout Vandecappelle
2017-10-17 19:03               ` Thomas Petazzoni [this message]
2017-10-17 23:11                 ` Arnout Vandecappelle
2017-10-18  6:57                   ` Thomas Petazzoni
2017-10-18  7:44                     ` Anisse Astier
2017-10-18  7:58                       ` Thomas Petazzoni
2017-10-18  8:09                         ` Anisse Astier
2017-10-18  8:11                           ` Thomas Petazzoni
2017-10-18  9:05                             ` Anisse Astier
2017-10-18  9:10                               ` Thomas Petazzoni
2017-10-18 10:54                                 ` Arnout Vandecappelle
2017-10-18 11:36                                   ` Thomas Petazzoni
2017-10-18 10:57                     ` Arnout Vandecappelle
2017-10-18 11:36                       ` Thomas Petazzoni
2017-10-18 17:42                         ` Yann E. MORIN
2017-10-17 15:45           ` Anisse Astier
2017-10-17 22:58             ` Arnout Vandecappelle
2017-10-18  6:53               ` Thomas Petazzoni
2017-10-18  7:34               ` Anisse Astier
2017-10-17 15:53   ` Anisse Astier

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=20171017210354.38d89b3c@windsurf.lan \
    --to=thomas.petazzoni@free-electrons.com \
    --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.