From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 0/3] Fix for top-level parallel make part 1
Date: Tue, 30 Jul 2013 13:29:01 +0200 [thread overview]
Message-ID: <20130730132901.0682e15d@skate> (raw)
In-Reply-To: <CAHkwnC8SV6L=4a0ain-VysEw3Z8Jg_XLLUJWH1xo6T=FVeYO6A@mail.gmail.com>
Dear Fabio Porcedda,
On Tue, 30 Jul 2013 12:16:44 +0200, Fabio Porcedda wrote:
> > As we discussed in this thread, the problem is that the top-level
> > parallel make feature is broken if you don't have per-package sysroot:
> > builds become non-reproducible.
>
> Just to understand better, this is true only for packages with
> unexpressed dependencies, right?
> So if a build has only packages with full expressed dependencies the
> builds are reproducible?
Yes, that's correct.
The problem is that it is very hard to be sure that /all/
possible dependencies are expressed in the Buildroot .mk file. When
someone bumps the version of a package, we rarely go through the
details of the changes in the configure.{ac,in} to see if additional
optional dependencies have been added by the upstream developers. We
could very easily overlook such changes, which would lead to
unreproducible results. I wouldn't be annoyed at all if the result was
a big fat build failure that is clearly visible. What annoys me is that
the issue is very hard to notice: from one build to another, you will
get different results. That's very hard to track down for Buildroot
developers and very confusing for users. Imagine the kind of support
requests we will get when users will face such spurious build
differences, and how complex it will be to handle them if we don't have
any guarantees on the reproducibility of the build.
I'd really like to see top-level parallel build in Buildroot, but I
don't think we should do it at the expense of build reproducibility and
increase of users support complexity.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2013-07-30 11:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-18 9:12 [Buildroot] [PATCH v2 0/3] Fix for top-level parallel make part 1 Fabio Porcedda
2013-07-18 9:12 ` [Buildroot] [PATCH v2 1/3] package/Makefile.in: add a way to don't force jobs in sub-make Fabio Porcedda
2013-08-21 19:17 ` Arnout Vandecappelle
2013-07-18 9:12 ` [Buildroot] [PATCH v2 2/3] package: fix generic extract target for top-level parallel make Fabio Porcedda
2013-08-21 19:24 ` Arnout Vandecappelle
2013-08-22 7:44 ` Fabio Porcedda
2013-08-22 15:59 ` Arnout Vandecappelle
2013-08-23 11:31 ` Fabio Porcedda
2013-08-26 8:29 ` Fabio Porcedda
2013-08-27 6:01 ` Arnout Vandecappelle
2013-08-28 8:26 ` Fabio Porcedda
2013-08-23 7:36 ` Thomas Petazzoni
2013-08-23 8:00 ` Fabio Porcedda
2013-08-23 11:14 ` Thomas Petazzoni
2013-07-18 9:12 ` [Buildroot] [PATCH v2 3/3] package: fix generic patch " Fabio Porcedda
2013-07-18 9:38 ` [Buildroot] [PATCH v2 0/3] Fix for top-level parallel make part 1 Thomas Petazzoni
2013-07-19 15:41 ` Fabio Porcedda
2013-07-27 11:18 ` Thomas Petazzoni
2013-07-30 9:34 ` Fabio Porcedda
2013-07-30 10:01 ` Thomas Petazzoni
2013-07-30 10:16 ` Fabio Porcedda
2013-07-30 11:29 ` Thomas Petazzoni [this message]
2013-08-12 16:48 ` Arnout Vandecappelle
2013-08-20 12:14 ` Fabio Porcedda
2013-08-20 17:35 ` Arnout Vandecappelle
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=20130730132901.0682e15d@skate \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox