From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v7 0/8] Top-level parallel build support
Date: Fri, 1 Mar 2019 18:18:03 +0100 [thread overview]
Message-ID: <20190301171803.GD2721@scaer> (raw)
In-Reply-To: <20190301145043.GA20576@lwo1-lhp-f71841>
Vadym, All,
On 2019-03-01 16:50 +0200, Vadym Kochan spake thusly:
> On Mon, Feb 25, 2019 at 09:05:43AM +0100, Thomas Petazzoni wrote:
> > On Mon, 25 Feb 2019 03:10:03 +0200
> > Vadim Kochan <vadim4j@gmail.com> wrote:
> >
> > > I think that in case of per-packages parallel build the logs became
> > > messy and meaningless so I send a patch which allows to do per-package
> > > logging too:
> > >
> > > https://patchwork.ozlabs.org/patch/1047549/
> > >
> > > this is a POC so it just shows the idea.
> > The problem of logging was discussed quite a lot back when I started to
> > work on per-package directories. I think we investigated overriding the
> > SHELL variable, but couldn't find an approach that worked properly, but
> > maybe the approach was different than yours, I need to get back to the
> > original discussion.
> >
> > Back then, what we concluded is that people could use the "make
> > --output-sync=target" option, or "make -Otarget" in short. This option
> > buffers the output of make on a per-target basis, and displays this
> > output at once when the target has completed. The advantage is that the
> > output is no longer garbled, but the drawback is that you don't see
> > "live" what is happening: if a package takes 20 minutes to build,
> > during 20 minutes you see nothing, and at the end of the 20 minutes,
> > you get in one go the full build output of that package.
>
> I updated the patch:
>
> https://patchwork.ozlabs.org/patch/1047620/
>
> where I added per-package-and-per-step logging, I think it is possible
> to merge them info one log file, but per-step approach allows to easy
> update logs for perticular step.
>
> But I 'd like to clarify if actually such approach make sense ?
As Thomas said, we already have had some discussion about the logging,
and we also investigated using a shell wrapper, and a PoC similar to
yours was even attempted.
However, we eventually concluded that this was not going to work
reliably, so we decided against at that time. I could not find that
conclusion in the devdays meeting reports, so I guess it's burried
somewhere in the mailing list. I'll try to unearth those later in the
evening or the week-end...
The first issue I can readily remember, was that the SHELL variable is
passed down to all children, and some of them may re-use it to run
commands, and the wrapper would make those fail. I don't have the
details, though, as I said I'll try to dig them from the archives...
But overall, I agree with Thomas, that people that still want nice logs
call 'make -Otarget'.
> Also how do you think about to add (using the approach from the patch)
> prepending logs with a package name prefix (in bold) (not necessary for
> parellel building but enabled by config option):
>
> [${pkg_name}] $log_line
>
> after it may be possible to print the percentage of installed packages
> like:
>
> [${percent}][${pkg_name}] $log_line
>
> ofcourse all this is just for providing to user at runtime the info
> which package is building and how many packages (in percentages) are
> done. So, may be it looks useless, but I feel it would be nice to have.
Sorry, but I think this is really getting too far.
We already have a simple make wrapper, utils/brmake, which filters the
build log and redirects all to a file, and just prints the '>>>' lines
to stdout. I think this is as far as we should go with Buildroot.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2019-03-01 17:18 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-28 10:43 [Buildroot] [PATCH v7 0/8] Top-level parallel build support Thomas Petazzoni
2018-12-28 10:43 ` [Buildroot] [PATCH v7 1/8] support/scripts/check-host-rpath: document existing functions Thomas Petazzoni
2018-12-28 12:47 ` Yann E. MORIN
2019-01-17 21:33 ` Peter Korsgaard
2018-12-28 10:43 ` [Buildroot] [PATCH v7 2/8] Makefile: move definition of TARGET_DIR inside .config condition Thomas Petazzoni
2018-12-28 12:49 ` Yann E. MORIN
2019-01-17 21:35 ` Peter Korsgaard
2018-12-28 10:43 ` [Buildroot] [PATCH v7 3/8] core: implement per-package SDK and target Thomas Petazzoni
2018-12-30 21:52 ` Yann E. MORIN
2018-12-31 14:31 ` Thomas Petazzoni
2018-12-31 14:45 ` Yann E. MORIN
2019-01-08 18:02 ` Jan Kundrát
2019-11-05 16:38 ` Thomas Petazzoni
2019-11-05 19:05 ` Carlos Santos
2019-11-06 7:57 ` Thomas Petazzoni
2019-11-06 8:13 ` Jan Kundrát
2018-12-28 10:43 ` [Buildroot] [PATCH v7 4/8] Makefile: allow top-level parallel build with BR2_PER_PACKAGE_DIRECTORIES=y Thomas Petazzoni
2018-12-28 12:51 ` Yann E. MORIN
2018-12-28 10:43 ` [Buildroot] [PATCH v7 5/8] package/pkg-generic: make libtool .la files compatible with per-package directories Thomas Petazzoni
2018-12-31 8:44 ` Yann E. MORIN
2018-12-28 10:43 ` [Buildroot] [PATCH v7 6/8] package/pkg-kconfig: handle KCONFIG_DEPENDENCIES " Thomas Petazzoni
2018-12-28 10:43 ` [Buildroot] [PATCH v7 7/8] docs/manual: add details about top-level parallel build support Thomas Petazzoni
2018-12-28 13:03 ` Yann E. MORIN
2018-12-28 13:08 ` Thomas Petazzoni
2018-12-31 8:46 ` Yann E. MORIN
2018-12-28 10:43 ` [Buildroot] [PATCH v7 8/8] docs/manual: document the effect of per-package directory on variables Thomas Petazzoni
2018-12-28 17:21 ` [Buildroot] [PATCH v7 0/8] Top-level parallel build support Thomas Petazzoni
2019-02-22 16:18 ` Andreas Naumann
2019-02-22 18:07 ` Vadim Kochan
2019-02-22 20:29 ` Thomas Petazzoni
2019-02-25 1:10 ` Vadim Kochan
2019-02-25 8:05 ` Thomas Petazzoni
2019-02-25 8:33 ` Vadim Kochan
2019-03-01 14:50 ` Vadym Kochan
2019-03-01 17:18 ` Yann E. MORIN [this message]
2019-03-04 7:24 ` Arnout Vandecappelle
2019-03-04 10:22 ` Thomas Petazzoni
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=20190301171803.GD2721@scaer \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox