From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80806 invoked by alias); 13 Jun 2018 20:26:44 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 80790 invoked by uid 89); 13 Jun 2018 20:26:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,TVD_RCVD_SPACE_BRACKET autolearn=ham version=3.3.2 spammy=H*f:sk:7LpHgTY, H*f:Sn1, H*i:sk:7LpHgTY, H*i:Sn1 X-HELO: mutluit.com Received: from mutluit.com (HELO mutluit.com) (82.211.8.197) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Jun 2018 20:26:42 +0000 Received: from [37.139.71.2] (ip4d16cd28.dynamic.kabel-deutschland.de [77.22.205.40]:50030) by mutluit.com (s2.mutluit.com [82.211.8.197]:50025) with ESMTP ([XMail 1.27 ESMTP Server]) id for from ; Wed, 13 Jun 2018 22:26:39 +0200 Subject: Re: -v should print also the revision number in repo To: gcc@gcc.gnu.org References: <5B217148.7060408@mutluit.com> Cc: Andrew Pinski From: "U.Mutlu" Message-ID: <5B217DFE.9070204@mutluit.com> Date: Wed, 13 Jun 2018 20:26:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0 SeaMonkey/2.37a1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00163.txt.bz2 Andrew Pinski wrote on 06/13/2018 10:06 PM: > On Wednesday, June 13, 2018, U.Mutlu > > wrote: > > Hi, > > currently -v (ie. gcc -v) prints these data: > > gcc version 9.0.0 20180613 (experimental) (GCC) > > It would be nice, when building from a repository that then the resulting > target should contain also the revision number (for example "r261543") > of the underlying repository, so that gcc -v then prints this info as well. > > Maybe the respective revision nbr of the repository used (svn, git, ...), > or perhaps better: a new generic solution with a unique & common rev-nbr > for all repos (and non-repos): a new file with rev-info in the repo-root > could do the trick, IMO... > > > If you use contrib/gcc_update, it will place the right thing in the needed > file and will display the revision. Ah, cool! Will try it out, thx.