From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/6] pkg-infra: log current message
Date: Sun, 20 Jan 2013 15:38:21 +0100 [thread overview]
Message-ID: <20130120153821.6fc6853c@skate> (raw)
In-Reply-To: <50FBF5EA.5010303@mind.be>
Dear Arnout Vandecappelle,
On Sun, 20 Jan 2013 14:49:30 +0100, Arnout Vandecappelle wrote:
> I'm a bit concerned because this is another blocker for top-level
> parallel build (the contents of last-action will be incorrect).
I agree that top-level parallel build would be nice, but I'm wondering
whether it is realistic to think we will support it one day. The main
problem I'm seeing with top-level parallel build is that we need to
create a per-package sysroot in order to get reproducible builds.
For the moment, we install all the libraries and headers in
$(STAGING_DIR), and we point all packages to $(STAGING_DIR) as the
toolchain sysroot, so that they find their required dependencies.
For now, the fact that the sysroot is unique and global is not a
problem as the build is completely serialized, and therefore
reproducible. If package A has an optional dependency on package B (not
expressed in Buildroot dependencies, but package A detects if B is
available in its configure script, and if it is, then uses B), then
either B is built before A, and A has B support, or B is built after A,
and A doesn't have B support.
If you switch to top-level parallel build, then sometimes, B will be
built before A, sometimes after, leading to A sometimes having B
support, sometimes B.
Of course, one way of seeing this is "that's a Buildroot bug, package A
should explicit its optional dependency on package B in its .mk file".
Unfortunately, in practice, it's going to be very hard to track *all*
those optional dependencies, especially when we bump package versions
and those bumps introduce need optional dependencies.
The only way to solve this is to create a per-package sysroot, in which
we install only the headers and libraries that the package explicitly
list as part of its dependencies. I know OpenBricks is doing that. And
I remember discussing with the OE-lite maintainer as this problem being
in his opinion the #1 reliability problem in OpenEmbedded.
Do we want to implement this per-package sysroot thing?
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-01-20 14:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-16 23:41 [Buildroot] [pull request] Pull request for branch yem-instrument-build Yann E. MORIN
2013-01-16 23:41 ` [Buildroot] [PATCH 1/6] pkg-infra: log current message Yann E. MORIN
2013-01-17 15:22 ` Markos Chandras
2013-01-20 13:49 ` Arnout Vandecappelle
2013-01-20 14:10 ` Yann E. MORIN
2013-01-20 14:38 ` Thomas Petazzoni [this message]
2013-01-20 14:59 ` Yann E. MORIN
2013-01-16 23:41 ` [Buildroot] [PATCH 2/6] toolchain/external: sprinkle with some calls to MESSAGE Yann E. MORIN
2013-01-20 13:51 ` Arnout Vandecappelle
2013-01-16 23:41 ` [Buildroot] [PATCH 3/6] toolchain/crosstool-ng: " Yann E. MORIN
2013-01-20 13:56 ` Arnout Vandecappelle
2013-01-20 14:27 ` Yann E. MORIN
2013-01-16 23:41 ` [Buildroot] [PATCH 4/6] toolchain/gcc: " Yann E. MORIN
2013-01-18 16:13 ` Markos Chandras
2013-01-20 14:01 ` Arnout Vandecappelle
2013-01-16 23:41 ` [Buildroot] [PATCH 5/6] toolchain/kernel-headers: " Yann E. MORIN
2013-01-18 16:16 ` Markos Chandras
2013-01-20 14:04 ` Arnout Vandecappelle
2013-01-16 23:41 ` [Buildroot] [PATCH 6/6] toolchain/uClibc: " Yann E. MORIN
2013-01-18 16:12 ` Markos Chandras
2013-01-20 14:02 ` [Buildroot] [pull request] Pull request for branch yem-instrument-build Arnout Vandecappelle
2013-01-20 14:03 ` [Buildroot] [PATCH] fs/common.mk: delay evaluation of variables Arnout Vandecappelle
2013-01-20 19:59 ` Peter Korsgaard
2013-01-20 14:10 ` [Buildroot] [pull request] Pull request for branch yem-instrument-build Thomas Petazzoni
2013-01-20 14:22 ` Yann E. MORIN
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=20130120153821.6fc6853c@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 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.