Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Build reproducibility
Date: Tue, 3 Sep 2013 18:48:38 +0200	[thread overview]
Message-ID: <20130903184838.37f44e53@skate> (raw)
In-Reply-To: <87ioyi73el.fsf@dell.be.48ers.dk>

Dear Peter Korsgaard,

(Adding Fabio to the CC list)

On Tue, 03 Sep 2013 09:47:14 +0200, Peter Korsgaard wrote:

>  Thomas> This would certainly be nice to have (as it also helps
>  Thomas> top-level parallel build, as was discussed with Fabio
>  Thomas> Porcedda some time ago), but:
> 
> [snip]
> 
> Indeed. For the record, I also don't think we should do this, I was
> just stating what was needed if we wanted to do so.
> 
> As long as the dependencies are correct, I don't think seperate
> staging dirs are needed for toplevel parallel builds.

I disagree on this one. Since there is no way to be sure that all the
possible optional dependencies have been taken into account, I believe
separate staging dirs are a requirement to ensure that toplevel
parallel builds are reproducible.

Whenever we bump a package, some additional optional dependencies may
have been added by the upstream developers, and we rarely go deep into
the configure.ac script or other build system files to verify that the
addition or removal of optional dependencies. Having to do such review
work would be very time-consuming and terribly annoying. So the only
way to be sure that the optional dependencies are all properly taken
into account when doing top-level parallel build is by ensuring that
the staging dir used when building a package only contains the
dependencies that have been explicitly listed by the package .mk file.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2013-09-03 16:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-30  8:31 [Buildroot] Build reproducibility Jérôme Pouiller
2013-08-30  8:31 ` [Buildroot] [PATCH] Fix build reproducibility in Make 3.82 Jérôme Pouiller
2013-09-03  6:13   ` Arnout Vandecappelle
2013-09-03  8:45     ` [Buildroot] [PATCH v2] " Jérôme Pouiller
2013-09-03  9:31       ` Arnout Vandecappelle
2013-09-07  6:06       ` Peter Korsgaard
2013-08-30 11:59 ` [Buildroot] Build reproducibility Thomas De Schampheleire
2013-08-30 12:44   ` Jérôme Pouiller
2013-08-30 12:52     ` Thomas Petazzoni
2013-09-02  8:44       ` Thomas De Schampheleire
2013-09-02  8:53         ` Thomas Petazzoni
2013-09-02 13:18           ` Thomas De Schampheleire
2013-09-03 17:13             ` Thomas Petazzoni
2013-09-05 19:56               ` Thomas De Schampheleire
2013-09-05 20:49                 ` Jérôme Pouiller
2013-09-02 16:11         ` Arnout Vandecappelle
2013-09-03  6:26           ` Peter Korsgaard
2013-09-03  7:16             ` Thomas Petazzoni
2013-09-03  7:47               ` Peter Korsgaard
2013-09-03 16:48                 ` Thomas Petazzoni [this message]
2013-09-03  8:15             ` Jérôme Pouiller
2013-09-03 16:54               ` 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=20130903184838.37f44e53@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