From: Alan Modra <amodra@gmail.com>
To: Petr Ovtchenkov <ptr@void-ptr.info>
Cc: Joel Brobecker <brobecker@adacore.com>,
Matthias Klose <doko@ubuntu.com>,
Simon Marchi <simon.marchi@polymtl.ca>,
Pedro Alves <palves@redhat.com>, Matt Rice <ratmice@gmail.com>,
Fiodar Stryzhniou <fedor_qd@mail.ru>,
Andreas Schwab <schwab@linux-m68k.org>,
Binutils <binutils@sourceware.org>, GDB <gdb@sourceware.org>
Subject: Re: meaning of "Automatic date update in version.in" commits
Date: Thu, 21 Sep 2017 23:59:00 -0000 [thread overview]
Message-ID: <20170921235936.GB25070@bubble.grove.modra.org> (raw)
In-Reply-To: <20170921203857.06810b63@void-ptr.info>
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.
Yes, it would be nice if the automatic date stamp update didn't happen
when the most recent commit was a date update..
--
Alan Modra
Australia Development Lab, IBM
next prev parent reply other threads:[~2017-09-21 23:59 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-21 5:03 Fiodar Stryzhniou via gdb
2017-09-21 8:42 ` Matt Rice
2017-09-21 10:58 ` Petr Ovtchenkov
2017-09-21 11:37 ` Pedro Alves
[not found] ` <20170921152240.16bb4cc0@void-ptr.info>
2017-09-21 12:39 ` Pedro Alves
2017-09-21 13:17 ` Petr Ovtchenkov
2017-09-21 13:34 ` Simon Marchi
2017-09-21 15:46 ` Petr Ovtchenkov
2017-09-21 16:01 ` Simon Marchi
2017-09-21 16:03 ` Matthias Klose
2017-09-21 16:26 ` Petr Ovtchenkov
2017-09-21 16:34 ` Joel Brobecker
2017-09-21 16:52 ` Petr Ovtchenkov
2017-09-21 17:00 ` Joel Brobecker
2017-09-21 17:39 ` Petr Ovtchenkov
2017-09-21 23:59 ` Alan Modra [this message]
2017-09-22 5:31 ` Petr Ovtchenkov
2017-09-22 6:49 ` Andreas Schwab
2017-09-22 9:29 ` Petr Ovtchenkov
2017-09-22 22:26 ` H.J. Lu
2017-09-22 22:35 ` H.J. Lu
2017-09-22 9:49 ` [PATCH] bfd/version.h: Add rationale for BFD_VERSION_DATE (Re: meaning of "Automatic date update in version.in" commits) Pedro Alves
2017-09-22 13:38 ` Alan Modra
2017-09-22 13:47 ` Joel Brobecker
2017-09-22 13:59 ` Pedro Alves
2017-09-21 17:17 ` meaning of "Automatic date update in version.in" commits Joseph Myers
2017-09-21 17:31 ` Matt Rice
[not found] <20170920173622.28500ccf@void-ptr.info>
2017-09-20 15:05 ` Joel Brobecker
2017-09-20 15:33 ` Petr Ovtchenkov
2017-09-21 17:07 ` Ian Lance Taylor via gdb
2017-09-20 15:40 ` Matthias Klose
2017-09-20 15:48 ` Dmitry Samersoff
[not found] ` <87zi9p2vma.fsf@linux-m68k.org>
2017-09-20 17:24 ` Petr Ovtchenkov
[not found] ` <7217d33d-61eb-732e-dfd6-80ef4908743e@ubuntu.com>
2017-09-20 19:21 ` Petr Ovtchenkov
2017-09-20 19:27 ` Mikhail Terekhov
2017-09-20 19:56 ` Philippe Waroquiers
2017-09-20 19:57 ` Matthias Klose
2017-09-20 20:07 ` Philippe Waroquiers
2017-09-20 20:21 ` Matthias Klose
2017-09-20 20:26 ` Philippe Waroquiers
2017-09-20 20:31 ` Petr Ovtchenkov
2017-09-20 20:39 ` Philippe Waroquiers
2017-09-20 20:34 ` Mikhail Terekhov
2017-09-20 21:34 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170921235936.GB25070@bubble.grove.modra.org \
--to=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=brobecker@adacore.com \
--cc=doko@ubuntu.com \
--cc=fedor_qd@mail.ru \
--cc=gdb@sourceware.org \
--cc=palves@redhat.com \
--cc=ptr@void-ptr.info \
--cc=ratmice@gmail.com \
--cc=schwab@linux-m68k.org \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox