Provide build number in include/generated/version.h

[carlescufi]

We would like to have a build number (i.e. the amount of times one has built a kernel tree) as part of the version.h set of macros. This is akin to the build number in Linux, as shown:

Zephyr 1.9-rc2 #1559 Mon Jul 17 16:32:11 UTC 2017 nRF51

The 1559 is the build number.

[carlescufi]

@holtmann this won't be ready for 1.9, so for now we'll need to make do with what's in #1331

[dbkinder]

One of the Linux Foundation CII Best Practices requirements (we're trying to meet) is, "The project MUST be able to repeat the process of generating information from source files and get exactly the same bit-for-bit result." Are we doing (or about to do) things that would prevent this?

Ref: https://bestpractices.coreinfrastructure.org/projects/74?criteria_level=1#changecontrol

[galak]

I think its the case today if we include a date stamp, include a build number actually is less of an issue to get the exact bit-for-bit results.

[pfalcon]

Perhaps we should include git revision instead (or $(git describe) )

[carlescufi]

@pfalcon yes, that's a good idea. git SHA, timestamp, and build count could all be part of version.h

[pfalcon]

timestamp and build count would contradict that recent "reproducible build" frenzy ;-). (Which isn't bad on its own, but indeed conflicts with expectations of many people, and given that there're, and will be, many compilers out there, seem like a real frenzy pushed forward IMHO.)

[carlescufi]

@pfalcon how is a timestamp against reproducibility? anyway for a reproducible build my guess is that the only thing required is the Git SHA and then whatever command-line argument was used to compile it

[pfalcon]

how is a timestamp against reproducibility?

Quoting what was quoted by @dbkinder above: "The project MUST be able to repeat the process of generating information from source files and get exactly the same bit-for-bit result."

As timestamp changes from build to build, your customer or user won't be able to reproduce the exactly same binary as you shipped them from some source (and thus verify that you didn't include backdoors and stuff in the binary which isn't available in the source). Again, IMHO it's a bit far-fetched, as there're lot of other things affecting reproducibility, but if the above is in the Linux Foundation best practices, then d'oh.