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

Do not store build host name #3312

Merged
merged 3 commits into from Feb 28, 2019

Conversation

Projects
None yet
3 participants
@bmwiedemann
Copy link
Contributor

bmwiedemann commented Feb 27, 2019

  • I have created a new test or updated the unit tests to cover the new/changed functionality.
  • I have updated master/src/CHANGES.txt directory (and read the README.txt in that directory)
  • I have updated the appropriate documentation

Do not store build host name
if reproducible builds are wanted.
See https://reproducible-builds.org/ for why this is good.

This affected scons itself, which differed in the line

__buildsys__ = "..."

@bmwiedemann bmwiedemann force-pushed the bmwiedemann:host branch 2 times, most recently from 8d5f445 to 19cd3e4 Feb 27, 2019

@bdbaddog

This comment has been minimized.

Copy link
Contributor

bdbaddog commented Feb 27, 2019

Would it be better to have REPRODUCiBLE_BUILDS as the key environment variable, or is SOURCE_DATE_EPOCH a standard defined for all reproducible builds?

@bmwiedemann

This comment has been minimized.

Copy link
Contributor Author

bmwiedemann commented Feb 28, 2019

So far, everyone wanting reproducible build results sets SOURCE_DATE_EPOCH - defined in https://reproducible-builds.org/specs/source-date-epoch/ ; adding another variable would be possible but mean extra effort for people to discover and set it.

@mwichmann

This comment has been minimized.

Copy link
Collaborator

mwichmann commented Feb 28, 2019

If I'm getting this, this patch proposes, for the construction of an scons release, to honor SOURCE_DATE_EPOCH if it is set, as a flag for not deriving the build host, but not otherwise used. Shouldn't it also be used to fill in the date field, which is currently the time scons was run, and thus will vary? Not sure I think "reproducible" is the best magic string, maybe with a leading underscore to mark it as special? It also looks like the same can be achieved by externally setting BUILD_SYSTEM to the magic string, though as noted, that's something extra for people to discover. As one more nit, at the very least some more docu is needed on this... for example, if you don't pass in DEVELOPER it will still be set by inspection, and thus give you different results if different people do the build.

bmwiedemann added some commits Feb 27, 2019

Do not store build host name
if reproducible builds are wanted.
See https://reproducible-builds.org/ for why this is good.

This affected scons itself, which differed in the line

    __buildsys__ = "..."

@bmwiedemann bmwiedemann force-pushed the bmwiedemann:host branch from 19cd3e4 to 46fe477 Feb 28, 2019

@bmwiedemann

This comment has been minimized.

Copy link
Contributor Author

bmwiedemann commented Feb 28, 2019

DATE is already using SOURCE_DATE_EPOCH since #3221

I updated the commit to use _reproducible to mark it as more special and added a 2nd commit for DEVELOPER

@bdbaddog

This comment has been minimized.

Copy link
Contributor

bdbaddog commented Feb 28, 2019

So far, everyone wanting reproducible build results sets SOURCE_DATE_EPOCH - defined in https://reproducible-builds.org/specs/source-date-epoch/ ; adding another variable would be possible but mean extra effort for people to discover and set it.

O.k. If that's the common practice. I'll go ahead and merge.

@mwichmann

This comment has been minimized.

Copy link
Collaborator

mwichmann commented Feb 28, 2019

Ah, I missed the earlier change. Looking okay to me, but we'll wait for the Boss :)

Does scons need to be taught anything as far as producing reproducible builds? (as opposed to the build of scons itself) Unrelated, just curious.

@bdbaddog bdbaddog merged commit 7a32722 into SCons:master Feb 28, 2019

1 of 3 checks passed

continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
Sider No issues found!
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.