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

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

On Fri, 22 Sep 2017 09:29:36 +0930
Alan Modra <amodra@gmail.com> wrote:

> On Thu, Sep 21, 2017 at 08:38:57PM +0300, Petr Ovtchenkov wrote:
> > On Thu, 21 Sep 2017 10:00:31 -0700
> > Joel Brobecker <brobecker@adacore.com> wrote:
> > 
> > > > It is evident for me. But in the discussion I see a lot of arguments,
> > > > that I treat as "date stamp is used as ABI compatibility marker". 
> > > 
> > > Then, I am in the same situation as Pedro. What problem are you trying
> > > to fix?
> > 
> > Oops. Let's start from the begining. Far far away...
> > 
> > 1. Explicit "Automatic date update in version.in" commits litter commits tree,
> > but useless. All required info already present in git.
> > [Thanks for Ian Lance Taylor for the background!]
> 
> It isn't useless.  People build binutils from a variety of sources,
> git, tarballs, distro sources, then report bugs.  We want something
> that can easily identify the source they used.  The bfd version plus
> date is usually good enough for that purpose.
> 
> > Let's remove this "Automatic date update in version.in" commits.
> 
> No.  That won't happen unless we have something equivalent.  And it
> must work *without* git.
> 
> > 2. I see a lot of suggestions "Let's push date to SONAME, the date we
> > will take from ....".
> > 
> > I trying to prevent such "solutions". Because it's not a solution, but
> > origin of another problems.
> 
> The date is in the soname because people naturally expect shared
> libraries with the same soname to have compatible ABIs.  During
> development, we could bump the bfd version on every ABI change, but
> that's just another thing contributors and maintainers would need to
> remember.  It's much easier for all if the soname contains the date.
> Again, it's not perfect but is good enough.
> 
> None of this is going to change just because you don't like a date
> stamp in the source.  You do realize that a bisect uses a binary
> search, don't you?  So doubling the number of commits just needs one
> extra build/test step on average.

+1 _rebuild_ * 2 (binutils + gdb), i.e. ~ +730 rebuilds that may be avoided.
Because binutils present near the top of packages dependency tree,
even incremental rebuild will be big enough. Looks I'm really forget
something... Oh, different platforms! What multiplicator I should
substitute here? All this to "easily identify the source they used",
for example, for 7f904457..94552d96, not for ABI change indeed.
All this for "inexperienced" users that try to test development binutils.

> 
> Yes, it would be nice if the automatic date stamp update didn't happen
> when the most recent commit was a date update..
> 

I.e. development process of kernel or glibc (ABI is important and "source
identification" important too, isn't it?) dispense of such technique,
but binutils prefer to follow tradition from 1994 that was useful
for publicly inaccessible CVS repo + public tarball on FTP.

Looks I'm attempt a sacred caw. I should shut up.