From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30517 invoked by alias); 22 Sep 2017 05:31:55 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 30492 invoked by uid 89); 22 Sep 2017 05:31:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC autolearn=no version=3.3.2 spammy=shut, dispense, H*M:info X-Spam-User: qpsmtpd, 2 recipients X-HELO: void-ptr.info Received: from pppoe.185.44.68.223.lanport.ru (HELO void-ptr.info) (185.44.68.223) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Sep 2017 05:31:53 +0000 Received: from ptr by void-ptr.info with local (Exim 4.72) (envelope-from ) id 1dvGYv-0005gn-2c; Fri, 22 Sep 2017 08:31:41 +0300 Date: Fri, 22 Sep 2017 05:31:00 -0000 From: Petr Ovtchenkov To: Alan Modra Cc: Joel Brobecker , Matthias Klose , Simon Marchi , Pedro Alves , Matt Rice , Fiodar Stryzhniou , Andreas Schwab , Binutils , GDB Subject: Re: meaning of "Automatic date update in version.in" commits Message-ID: <20170922083141.6e968bd5@void-ptr.info> In-Reply-To: <20170921235936.GB25070@bubble.grove.modra.org> References: <8740f2a7-1300-3116-f34b-5487a8cd8b2b@redhat.com> <20170921161743.3ddc6bb9@void-ptr.info> <20170921184615.6b1e5d44@void-ptr.info> <426b9fdf-a854-6d5f-b296-df71ad0c1561@ubuntu.com> <20170921192619.412ff148@void-ptr.info> <20170921163358.twez7kbewucjalwi@adacore.com> <20170921195153.4ed9f319@void-ptr.info> <20170921170031.czr6to24sarve2or@adacore.com> <20170921203857.06810b63@void-ptr.info> <20170921235936.GB25070@bubble.grove.modra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00101.txt.bz2 On Fri, 22 Sep 2017 09:29:36 +0930 Alan Modra 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 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.