ludo@gnu.org (Ludovic Courtès) writes:
Toggle quote (9 lines)
> Currently .go files embed randomly-generated symbols stemming from> ‘syntax-session-id’, which prevents reproducible builds (see> <https://lists.gnu.org/archive/html/guix-devel/2013-09/msg00159.html>.)>> One way to fix it would be to allow users to specify a random seed used> when generating session ids, and to make that available as a> command-line option to ‘guild compile’. (GCC does something similar> with its ‘-frandom-seed’ option.)
We could add this, but it is not analogous to the -frandom-seed optionwhere it is okay to give it the same value everywhere. Users would needto ensure that distinct session-ids are used for every invocation ofGuile.
More precisely, users of this feature would need to observe thefollowing restriction, or else unspecified behavior may result:
If A.go is generated by a Guile session with session-id A, and B.go is generated by a Guile session with session-id B, and they are both loaded into a Guile session with session-id C, then A, B, and C must all be distinct session-ids.
One more thing: even with a deterministic session-id, the multi-threadedcompiling of *.go files recently added to Guix will lead tonon-deterministic outputs. I'm not sure how to make this workdeterministically with concurrency. Even if we switched to a fixednumber of concurrent processes with one thread each, when process Aattempts to load a .go file that is produced by process B, it is notdeterministic whether it will be there. If it is there, the macros inthat .go file will contain B's session-id, and if not, they will containA's session-id.
Toggle quote (2 lines)
> Probably, ‘syntax-session-id’ would have to be a SRFI-39 parameter
This might adversely affect the efficiency of our macro expander onplatforms with slow thread local variables, and I'm not sure what itwould buy us. If the idea is that it would allow us to build things inmultiple threads, I think that won't work anyway, for the reasons givenabove.
I'm not entirely sure I've not made a mistake in my thinking, however.
Regards, Mark