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] [PATCH v2 0/3] Fix for top-level parallel make part 1
Date: Sat, 27 Jul 2013 13:18:28 +0200	[thread overview]
Message-ID: <20130727131828.0442e227@skate> (raw)
In-Reply-To: <CAHkwnC8imHc+yWdkUeR6VdehBhpuux_xmKProHu7uFmmR50N8g@mail.gmail.com>

Dear Fabio Porcedda,

On Fri, 19 Jul 2013 17:41:42 +0200, Fabio Porcedda wrote:

> > I don't remember if we had this discussion in the past, but before
> > going down the road of supporting top-level parallel make in Buildroot,
> > I'd like to understand what is your plan to solve the most important
> > problem that top-level parallel make creates: the need to create
> > per-package sysroot, instead of the global single sysroot we have
> > today. Have you thought about this problem already? What solution do
> > you have for it?
> 
> I hadn't thought about that, thanks for pointing it out.

You're welcome. I believe that top-level parallel build is a bit like
the creation of binary packages: people initially believe that it's
fairly trivial to implement, but in reality, if you want to implement
it properly it's much more complex and maybe too complex for the KISS
principle of Buildroot.

> So before to add top-level parallel make support we must add
> per-package sysroot...
> That's a bad news for me, i was already wokring on the second part :-(
> 
> I can try to work to add per-package sysroot, but i've some doubts about that:
>  - Is per-package sysroot a desiderable feature regardless the
> top-level parallel makefile support?
>  - Is per-package an appropriate or overkill feature for buildroot?

Beyond top-level parallel support, per-package support is useful as it
ensures only the dependencies that are explicitly expressed in the
package .mk file are actually seen when building a given package. So
from a build correctness point of view, it's certainly a nice feature.

Now, whether it's overkill or not for Buildroot is hard to say. It
clearly would increase a bit the complexity of the package
infrastructure, but it's hard to guess whether this additional
complexity will be reasonable or not before doing some prototypes.

There is, however, another drawback than just complexity: build time.
With per-package sysroot, it means that for each package, you have to
create a completely new sysroot, which takes time.

> Do you know if the other build system use per-package sysroot solution
> to solve the same issue? like bitbake/os, debian, fedora, ...?

I know that Debian builds all its packages inside a chroot, in which
only the explicit Build-depends of that package are installed. So in
effect, it has per-package sysroot.

As per OpenEmbedded/Bitbake, I was told a few years ago that they were
not doing per-package sysroot, even though they are doing top-level
parallel builds, and that this was sometimes causing some spurious
failures or not completely reproducible builds. However, I haven't
verified this myself, and this statement was made some years ago, so it
may or may not longer be true.

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-07-27 11:18 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 [this message]
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
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=20130727131828.0442e227@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