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: Thu, 18 Jul 2013 11:38:09 +0200 [thread overview]
Message-ID: <20130718113809.663c6b58@skate> (raw)
In-Reply-To: <1374138746-23279-1-git-send-email-fabio.porcedda@gmail.com>
Dear Fabio Porcedda,
Thanks for your patches!
On Thu, 18 Jul 2013 11:12:23 +0200, Fabio Porcedda wrote:
> this is the first patch set for fixing top-level parallel make in buildroot,
> the common problem scattered in buildroot's top-level makefile is that in the
> rules it relies on the order of evaluation of the prerequisites,
> to be able to use top-level parallel make instead of reling on the left to
> right ordering of evaluation of the prerequisites we must add an explicit
> rule to describe the dependency.
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?
In case the problem is not clear, here is a quick summary. The global
sysroot we have today, in which all libraries and headers are
installed, works fine because we have a guarantee on the build order
that is consistent across rebuilds, because builds are non-parallel.
Now, let's introduce parallelization between builds of different
packages, and suppose package A has an optional dependency on package
B, but this dependency is not expressed in Buildroot Makefiles because
we haven't seen that package A could optionally use package B.
If you build things in parallel, then one build may lead to package A
having been built with support for package B, because package B was
built and installed in the sysroot prior to package A configure step.
The next build you do, package A may be built without support for
package B, because package A configure step is executed before package
B is installed into the sysroot.
So without doing *any* change in Buildroot or the configuration, two
consecutive builds would have different results, which is clearly not
nice.
The only solution to avoid this is to have a per-package sysroot, into
which only the dependencies explicitly listed in the package .mk files
are installed. It is probably not impossible to do with Buildroot, but
isn't completely simple either.
What are your plans in that respect?
Thanks!
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-18 9:38 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 ` Thomas Petazzoni [this message]
2013-07-19 15:41 ` [Buildroot] [PATCH v2 0/3] Fix for top-level parallel make part 1 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
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=20130718113809.663c6b58@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