New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Highs_compilation_date
to improve build reproducibility
#1735
Comments
I've got no attachment to Is it useful to have it in the build @galabovaa? |
Yes indeed.
The effect of that is that it changes the created binary that will be installed each day, for the exact same version of the source code. Caching systems tend to hash the build output and if it doesn't change, then it knows that nothing that depends on HiGHS has to be rebuilt. So an effect of inserting a compilation date is to invalidate build caches for HiGHS every day. |
OK, I think I understand. Although a hard-coded date is only created in the text file Hence we need to remove @odow : do you make use of |
Nope 👍 for reproducible builds. |
Thanks @odow, @galabovaa will remove all reference to
will return a "Not known" message, and be deprecated |
Highs_compilation_date
to improve build reproducibilityHighs_compilation_date
to improve build reproducibility
Closed by #1747 |
Thank you! |
Embedding a date/timestamp in the output of a build artifact makes a build non-reproducible. Build reproducibility matters for multiple reasons, like making security audits and build caching easier. For more on that, please see https://reproducible-builds.org/ and https://en.wikipedia.org/wiki/Reproducible_builds. The Wikipedia article note: "timestamps are "the biggest source of reproducibility issues."
Highs_compilation_date
also doesn't seem to add much value, because the git hash is also included in the build output, and that is more informative (it uniquely identifies the exact version of the code being built, while build date does not). Hence, it would be good to remove the compilation date info completely.I'll note that the Meson build is currently checking for
SOURCE_DATE_EPOCH
, which is already an improvement (distros often set this to make timestamps reproducible), but the CMake and Bazel builds do not. Adding this to the CMake/Bazel builds probably isn't worthwhile though, it makes the build more than less complex.The text was updated successfully, but these errors were encountered: