On Sat, Jun 18, 2016 at 08:38:21AM +0000, Jason White via
> On Friday, 17 June 2016 at 20:36:53 UTC, H. S. Teoh wrote:
> > - Assuming that a revision control system is in place, and a
> > workspace is checked out on revision X with no further
> > modifications, then invoking the build tool should ALWAYS,
> > without any exceptions, produce exactly the same outputs, bit
> > for bit. I.e., if your workspace faithfully represents
> > revision X in the RCS, then invoking the build tool will
> > produce the exact same binary products as anybody else who
> > checks out revision X, regardless of their initial starting
> > conditions.
> Making builds bit-for-bit reproducible is really, really hard to do,
> particularly on Windows. Microsoft's C/C++ compiler embeds timestamps
> and other nonsense into the binaries so that every time you build,
> even when no source changed, you get a different binary. Google wrote
> a tool to help eliminate this non-determinism as a post-processing
> step called zap_timestamp. I want to eventually include something
> like this with Button on Windows. I'll probably have to make a PE
> reader library first though.
Even on Posix, certain utilities also insert timestamps, which is very
annoying. An Scons-based website that I developed years ago ran into
this problem with imagemagick. Fortunately there was a command-line
option to suppress timestamps, which made things saner.
> Without reproducible builds, caching outputs doesn't work very well
> Moral of the story is, if you're writing a compiler, for the sake of
> build systems everywhere, make the output deterministic! For
> consecutive invocations, without changing any source code, I want the
> hashes of the binaries to be identical every single time. DMD doesn't
> do this and it saddens me greatly.
DMD doesn't? What does it do that isn't deterministic?
Elegant or ugly code as well as fine or rude sentences have something in
common: they don't depend on the language. -- Luca De Vitis