Fix for top-level parallel make part 1
Get series with b4
b4 am 20130730132901.0682e15d@skateVersions newest first · linked by author and title
- v2 Latest posting 4/42 of 3 patches 0 repliesNew
- v2 posting 3/40 of 3 patches 0 repliesSuperseded
- v2 posting 2/40 of 3 patches 0 repliesSuperseded
Earlier versions · 1
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v2 posting 1/4 | 0 of 3 patches | 0 replies | Superseded |
2 of 3 patches are in this archive. The cover letter announces 3.
Patches in v2 posting 4/4 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 2/3 | package: fix generic extract target for top-level parallel make | +0 | 1 reply | |
| 2/3 | package: fix generic extract target for top-level parallel make | +0 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [Buildroot] [PATCH v2 0/3] Fix for top-level parallel make part 1
Dear Fabio Porcedda,
Quoted 8 lines · Fabio Porcedda
Quoted 3 lines
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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com