On Mon, Jun 08, 2015 at 08:58:52PM +0200, Peter Stuge wrote:
Kevin O'Connor wrote:
If the new "VERSION=" parameter is not
provided then the default build
version remains unchanged.
I prefer Alex' patch, because it defaults to reproducible but
provides more information if the tree has been modified, all
A user parameter like your VERSION *on top of that* is fine, but why
not have reproducible by default like with Alex' patch when that
doesn't really lose any information?
I find value in the hostname and date on trouble reports - it helps
determine if the binary was built by a distribution and it can help
backtrack to the gcc/binutils/etc. versions.
Aha! Maybe we can do one even better then - and include explicit
information about the gcc/binutils/etc. versions instead of something
implicit in the hope that it helps backtrack. Having explicit
toolchain information is valuable also for reproducible builds.
Build date - sorry, I'm not convinced. This is another heuristic.
Build date together with toolchain is not a good unique identifier.
How about (calculating and?) showing a simple checksum of the binary
at runtime instead?
My point is that you and reproducible builds actually want the same
thing, but that your chosen method makes things more difficult for
reproducible builds, and I think we can find a method that works for
If someone can submit a patch that provides decent information on the
toolchain then I'm certainly open to using it instead. The toolchain
is quite varied though (binutils, gcc, make, shell, python, etc.) so
it's not an easy task.
A checksum doesn't help me - it can demonstrate something is different
in the toolchain, but gives no clue on what is different.
I find value
in the timestamp during debug cycles as a means of
verifying I'm running the correct code during a test run.
Maybe you agree that this is a corner case which could warrant a
little special effort, e.g. a new make debug.bin target, given the
benefits of having the default build be reproducible?
So, I'm against changing the default to lose
this information -
either in the debault SeaBIOS build or the default coreboot build.
But only because the current suggestions mean you lose information,
right? Not per se?