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.

[marc-hb]

@carlescufi since commit 39131dc you now can override version.h with anything you like thanks to the BUILD_VERSION environment variable, do you think this is (flexible) enough to close this feature request? I have admittedly not tested this on Windows, please report any issue either in PR #14594 or create a new issue referencing PR #14594

On the more general reproducibility topic follow progress in PR #14593

[carlescufi]

@marc-hb thanks for the comment. The issue here is that this is part of a specification that allows a user to retrieve those values (including build number) from a controller. This is in common code, so my objective is to be able to provide a generic build number by default when compiling a zephyr-based application, without the user having to override version.h. If we do not intend to support this feature upstream by default then I can close this issue, and then we'll be returning the patch level like we are doing now:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/hci/hci.c#L1820

[marc-hb]

Understood, thx. Curious where such a build counter would be stored and when/how it would be reset: in the build directory or in the source tree? Would not count the same thing and interesting race condition in the latter case.

From a build reproducibility perspective, requesting to start from a totally pristine checkout (so: counter=0) is a very reasonable requirement.

[marc-hb]

One reason I suggested the environment variable is because a "build number" is usually something coming from outside the build and provided by Jenkins, buildbot or shippable etc. So "build counter" seems like a more accurate description.

I had a closer look at the dynamic BUILD_VERSION and I found that it's mostly unrelated to the static/manual KERNEL_VERSION_*. So my suggestion was wrong: no, right now you cannot the BUILD_VERSION environment variable to override anything you currently do with KERNEL_VERSION_*, those are two different features (In fact no one seems to care about BUILD_VERSION besides the boot banner) Please help review the code comments I'm adding in new PR #15950 to save others the confusion I experienced there.

Since you need something dynamic/fast-changing for these feature requests, maybe you should first switch away from the static KERNEL_VERSION_* to the more dynamic BUILD_VERSION? Or use some mix of both? My 2 cents.

[carlescufi]

N/A anymore