recording date potentially leads to non-reproducible builds

[ghost]

https://github.com/kevinlawler/kona/blob/master/Makefile#L122 in my experience leads to non-reproducible builds (see https://reproducible-builds.org/) as it records a timestamp, which could change when the build of the same source is repeated on the different days assuming that the build environment does not reset the date.

If you can tell me what you want to achieve with this, I can prepare a patch which still satisfies your requirement.

a solution to this is 66852b3

[tavmem]

Including the KBUILD_DATE in Makefile

	echo "#define KBUILD_DATE \"`date +%Y-%m-%d`\"" >$@

was first done in commit 2dd1367
titled " merge pahihu: replaced _k value with ISO date"
done on Dec 10, 2015.

This was part of a series of merges authored by @pahihu
I have no idea what @pahihu was trying to achieve.

Your solution seems fine.
Alternatively, IMHO, the KBUILD_DATE can be removed completely.

[pahihu]

Hi Tom, I’ve frustrated with not being able to check the build date of my different Kona versions. I’ve used a simple scheme: when I added/fixed something, I’ve built a Kona binary. Of course, you can completely remove that change. Regards, Andras Pahi

…

On 2019. Dec 30., at 18:11, Tom Szczesny ***@***.***> wrote: Including the KBUILD_DATE in Makefile echo "#define KBUILD_DATE \"`date +%Y-%m-%d`\"" >$@ was first done in commit 2dd1367 <2dd1367> titled " merge pahihu: replaced _k value with ISO date" done on Dec 10, 2015. This was part of a series of merges authored by @pahihu <https://github.com/pahihu> I have no idea what @pahihu <https://github.com/pahihu> was trying to achieve. Your solution seems fine. Alternatively, IMHO, the KBUILD_DATE can be removed completely. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#578?email_source=notifications&email_token=ADTEB24R6JHPQFM2WORDJTTQ3ITRRA5CNFSM4KBLHKL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH2X56I#issuecomment-569736953>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADTEB2YQXSJHGE4R6FECU3DQ3ITRRANCNFSM4KBLHKLQ>.

[bakul]

Do you want to check the build date or the commit date? The latter would give you reproducible builds as well as tell you what sources a binary was built from.

[pahihu]

Of course, the commit date. When I change something in my Kona version I push the changes to the GitHub repo and build a binary. I am interested in what sources a binary was built from.

…

On 2020. Feb 8., at 9:46, Bakul Shah ***@***.***> wrote: Do you want to check the build date or the commit date? The latter would give you reproducible builds as well as tell you what sources a binary was built from. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#578?email_source=notifications&email_token=ADTEB2ZST3LGORHC37H6UI3RBZWPDA5CNFSM4KBLHKL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELFNAFY#issuecomment-583716887>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADTEB2ZYCBJW37ZQVIPERMLRBZWPDANCNFSM4KBLHKLQ>.

[bakul]

In that case you can put something like the following in the Makefile:

VERSION=$(shell git rev-parse --short HEAD)
CLFAGS+=-DVERSION=$(VERSION)

And change the code to print out the version in the k banner. For example,

$ ./k
kona version c62db03.  Type  \ for help. \\ to exit.

If you want more details such as date, you can always do git cat-file -p <version>

[ghost]

In that case you can put something like the following in the Makefile:

VERSION=$(shell git rev-parse --short HEAD)
CLFAGS+=-DVERSION=$(VERSION)

I assume in a rule which is used to produce the tarball and Makefile for the distribution, because having the assumption for the release that it's a git checkout is a bad idea (which I guess you know).