I don't understand what drives this, maybe Sebastian can comment. I agree with Chris that requiring a documented "grep -v" in an expected output script would assist in reproducibility and process validation.
I also agree with Sebastian that "cmp" returning that files are identical is very reassuring. > On Dec 8, 2014, at 16:42 , Chris Johns <chr...@rtems.org> wrote: > > On 9/12/2014 8:07 am, Gedare Bloom wrote: >> On Mon, Dec 8, 2014 at 3:52 PM, Chris Johns <chr...@rtems.org> wrote: >>> On 8/12/2014 5:48 pm, Sebastian Huber wrote: >>>> >>>> This makes the report reproducible. >>> >>> >>> I think the report should include a date. I do not see any advantage having >>> reproducible reports. The report captures the specific instance of the >>> build. >>> >> Would it make sense to re-build on a different date and want to >> compare the results to see there is no difference? > > What you build on a different date cannot be the same by definition. > The date has changed. In a quality context if you reference the first > build that is what you have. You cannot reference an initial build and > then say you used a subsequent build because you know it is the same. > Where is the dated report to say they are same ? The report is about > reporting what you did and what happened. > >> Maybe a flag can be turned on/off for "reproducible" builds. > > I do not like flags being available for things like this. The user then > needs to audit the setting and this moves the compliance back up to the > user. > >> Or is it the user's >> responsibility to strip out such non-reproducible bits if they want >> such a feature? > > I can understand an MD5 hash on the components built and that result > being in a report. I have never tried to see if a repeat build of the > tools produces an exact binary image. > > I can also understand a user explicitly adding an exemption to an audit > process not to check the report. For example it is common to see target > binary images have exemptions for date and time strings embedded in them > and a manual audit with a hex dump to verify this is the only difference. > > Chris > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
