Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov <ptr@void-ptr.info>]

On Thu, 21 Sep 2017 18:01:59 +0200
Matthias Klose <doko@ubuntu.com> wrote:

> On 21.09.2017 17:46, Petr Ovtchenkov wrote:
> > On Thu, 21 Sep 2017 15:25:53 +0200
> > Simon Marchi <simon.marchi@polymtl.ca> wrote:
> > 
> >> On 2017-09-21 15:17, Petr Ovtchenkov wrote:
> >>> And date stamp in version.in not play here at all. But,
> >>>
> >>>   - if you insert date stamp into sources, you
> >>>     i)  keep "litter" problem
> >>>     ii) make misorientation (what this date mean? commit date? - it 
> >>> already
> >>>        present in commit; and what commit date?)
> >>>   - if you don't insert date stamp into sources, but add to SONAME
> >>> during build process,
> >>>     it still not reflect ABI compatibilities, but may prevent "binary
> >>> reproducible builds"
> >>>     (depends upon what date you use). I'm underline, that such addition
> >>>     has no relation to ABI compatibilities, so such SONAME modification
> >>>     lose sense.
> >>
> >> Binary reproducible builds mean that if you and I start with the same 
> >> source code and same build tools, we will get exactly the same build 
> >> artifacts.  Here the build can't "depend on what date you use":
> > 
> > If "date stamp" inserted into binary is a build date, then we will have different
> > binaries.
> 
> but it not a build date. it is a string taken form a file in the repository.
> That's exactly what Simon wrote at the end of the last message, and which you
> ignored to read or comment. Please see below.

Ok. I just expect that you read my arguments too. But in this case you ignore

<snip>
git show 3110f4be18a2
  commit 3110f4be18a2f3b9fcd9663ed1dd141bbd6ed14f
  Author: GDB Administrator <gdbadmin@sourceware.org>
  Date:   Wed Sep 20 00:01:01 2017 +0000

      Automatic date update in version.in

  diff --git a/bfd/version.h b/bfd/version.h
  index 3405e42..955269f 100644
  --- a/bfd/version.h
  +++ b/bfd/version.h
  @@ -1,4 +1,4 @@
  -#define BFD_VERSION_DATE 20170919
  +#define BFD_VERSION_DATE 20170920
   #define BFD_VERSION @bfd_version@
   #define BFD_VERSION_STRING  @bfd_version_package@ @bfd_version_string@
   #define REPORT_BUGS_TO @report_bugs_to@

git show f625a739     
  commit f625a739e567f0110b2675539b7a0e5d5f67c5dc
  Author: GDB Administrator <gdbadmin@sourceware.org>
  Date:   Wed Sep 20 00:01:22 2017 +0000

      Automatic date update in version.in

  diff --git a/bfd/version.h b/bfd/version.h
  index 3405e42..955269f 100644
  --- a/bfd/version.h
  +++ b/bfd/version.h
  @@ -1,4 +1,4 @@
  -#define BFD_VERSION_DATE 20170919
  +#define BFD_VERSION_DATE 20170920
   #define BFD_VERSION @bfd_version@
   #define BFD_VERSION_STRING  @bfd_version_package@ @bfd_version_string@
   #define REPORT_BUGS_TO @report_bugs_to@

git diff 3110f4be18a2 f625a739
...
Ooops....
</snip>

Same date. From both commits I can build libbfd. From equality of dates stamped in the source
not follow ABI compatibility.
Plus

  git diff 0d8a80b95 7a261482f

---from different stamped dates not follow ABI incompatibility.

Or I suspect that you conceal that date stamp not intended to reflect ABI compatibility,
but something else.

> 
> > If we will use something else, for example "last commit" date,
> > then we may have "same" build, but may not. From equality of "last commit" date
> > not follow binary equivalence (consider cherry-picked commit, for example,
> > or variations of sample "git diff 3110f4be18a2 f625a739" I show above).
> > 
> >> you 
> >> can't choose a date or another, the date is part of the code you are 
> >> trying to build.  So if you and I build from the same commit, we'll 
> >> build using the same date, whatever date is in the version.h file.