> A build is reproducible if given the same source code, build environment and build instructions
Same bits into input - some bits out of output.
Edit: formatting.
It can be simple things (something includes timestamps in binaries, which can be worked around by pinning the time), and complex things (concurrent linking of binaries is done FIFO-style, and different compilation units finish at different times in different runs because of varying processor load).
assuming that "build environment" includes more things than the author does (*it's* *not* *exactly* *a* *well-defined* *term*)
There is a lot of randomness in a typical build system: randomly ordered lists, race conditions in multithreaded coded, timestamps in the filesystem, etc, The worse kind of build systems can even include fetching files the internet. So, no, for all practical purposes actual computers are not deterministic and this is not tautological at all.
You can try to emulate determinism using some kind of virtual machine and run your build there (for example, see Hermit[1]), but it will never be perfect determinism and there are many practical downsides.
My point is: without very precise definition of "same build environment" all discussion of reproducible builds are almost meaningless.
I see people working on reproducible builds understanding exactly what they work on and having successful conference talks. I understand their goal too. It could be less vague in the explanation on the website, but... There's a common understanding you seem to be missing, but that doesn't make the discussions/work meaningless.
For example listing files in a directory and adding them to a list for further processing, without explicitly sorting by some stable criteria like filename.
I have some bad news.