Re: [Reduce-algebra-developers] How to build REDUCE reproducibly?

[Arthur N. <ac...@ca...>]

The state of play today is (I believe) as follows:

If one builds two copies of anything in different directories then there 
are loads of divergencies. I do not know if people keen on reproducability 
want it to extend that far, so until that is explained (and other things 
sorted!) I will not address that issue. Certainly at present information 
about source paths and build locations tends to get captured...

If I clean up a source directory in a way I expected to be comprehensive 
and then configure and build - then copy all that somewhere else and 
repeat the process - I think I find (on Linux at least) that the csl, 
bootstrapreduce and reduce executables and csl.img end up bit for bit in 
agreement but bootstrapreduce.img and reduce.img do not even end up the 
same size from the two consecutive builds.
Well image files go through a compression process so changes in content - 
even if small - may lead to a different file-size. And this is presumably 
EITHER a case where something is still sensitive to the clock or or
sensitive to memory layout that can change with Linux memory address 
randomization.

The debugging paths for this that I can see right now look somewhat time 
consuming! I can make a trick version that does not use compression on 
image files so that narrowing down what changes is easier. I can enable 
the trace of serialization that will generate maybe gigabytes of log as 
images files are created. I can make trick "mini reduce" versions building 
with fewer and fewer packages in the hope tha that ends with a smaller 
example to look into. Or eyeballing code a lot.

Unless inspiration hits me or somebody responds to this with a comment 
that helps enough I will go and mull over this and work on othet projects 
for a bit... and hope to remember or be prodded into coming back to it 
later.

Of course as almost always when the cause of the variation is uncovered it 
will probably be obvious!

Arthur