Skip to content
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

Closed
rgommers opened this issue Apr 26, 2024 · 7 comments
Closed

Remove Highs_compilation_date to improve build reproducibility #1735

rgommers opened this issue Apr 26, 2024 · 7 comments
Assignees

Comments

@rgommers
Copy link
Contributor

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.

@jajhall
Copy link
Sponsor Member

jajhall commented Apr 26, 2024

HIGHS_COMPILATION_DATE is no longer printed in the logging header at run-time - only HIGHS_GITHASH - but are you referring to it appearing in build files like HConfig.h?

I've got no attachment to HIGHS_COMPILATION_DATE, as I've never used it, so was happy to remove it from the logging header.

Is it useful to have it in the build @galabovaa?

@rgommers
Copy link
Contributor Author

but are you referring to it appearing in build files like HConfig.h?

Yes indeed. src/lp_data/Highs.cpp contains:

const char* highsCompilationDate() { return HIGHS_COMPILATION_DATE; }

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.

@jajhall
Copy link
Sponsor Member

jajhall commented Apr 26, 2024

OK, I think I understand. Although a hard-coded date is only created in the text file HConfig.h, the actual value of HIGHS_COMPILATION_DATE is in the binary, so this changes if HiGHS is re-built.

Hence we need to remove HIGHS_COMPILATION_DATE completely. from the source code.

@odow : do you make use of HIGHS_COMPILATION_DATE appearing in the build files?

@odow
Copy link
Collaborator

odow commented Apr 27, 2024

Nope

👍 for reproducible builds.

@jajhall
Copy link
Sponsor Member

jajhall commented Apr 27, 2024

Thanks @odow, @galabovaa will remove all reference to HIGHS_COMPILATION_DATE , and

const char* highsCompilationDate()

will return a "Not known" message, and be deprecated

@jajhall jajhall changed the title Consider removing Highs_compilation_date to improve build reproducibility Remove Highs_compilation_date to improve build reproducibility Apr 30, 2024
@jajhall
Copy link
Sponsor Member

jajhall commented May 7, 2024

Closed by #1747

@jajhall jajhall closed this as completed May 7, 2024
@rgommers
Copy link
Contributor Author

rgommers commented May 7, 2024

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants