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

Install files in deterministic order #12789

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bmwiedemann
Copy link

It might not matter much, but it makes for nicer builddir-diffs without variations in install-log.txt

This PR was done while working on reproducible builds for openSUSE.

might not matter much, but it makes for nicer diffs
without variations in install-log.txt
@eli-schwartz
Copy link
Member

The install-log.txt should not normally matter, as it is only used internally by ninja uninstall.

@bmwiedemann
Copy link
Author

Nevertheless it adds noise to the builddir-diff when I am debugging other reproducible-builds issues. So I'd appreciate this being merged, if it does not cause problems.

@eli-schwartz
Copy link
Member

I'm not certain I understand what the goal is of diffing the builddir instead of the install dir. There are many files in the builddir that can vary, and anything inside of meson-*/ directories can essentially be assumed to be completely unpredictable databases of fuzz.

@bmwiedemann
Copy link
Author

It is one of my approaches to debugging unreproducible build results. e.g. if you have variations in a .so file, it often comes from variations in a .o file which might come from variations in a generated .c or .h or other intermediate file (that only exist in the build dir, but not the install dir).

@eli-schwartz
Copy link
Member

How do you deal with the test log, which is inherently random and must be in order to run parallel tests? This is just one example of things in the build directory which are private to meson and not build outputs, that may be random -- and it too is a log file.

Log files are inherently unpredictable, so I don't think it makes much sense to try to guarantee it will be reproducible. It should just be excluded from the diff.

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

Successfully merging this pull request may close these issues.

None yet

2 participants