From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22430 invoked by alias); 30 Mar 2019 17:25:05 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 22071 invoked by uid 89); 30 Mar 2019 17:24:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,URIBL_BLOCKED autolearn=ham version=3.3.1 spammy=regexps, H*f:sk:83imw5k, daily X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 30 Mar 2019 17:24:56 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id C8B921E016; Sat, 30 Mar 2019 13:24:53 -0400 (EDT) Subject: Re: GDB version as convenience variable To: Joel Brobecker , Eli Zaretskii Cc: gdb-patches@sourceware.org References: <83r2aun9mk.fsf@gnu.org> <9d445bd2-28dd-be84-5414-510e061e4db1@simark.ca> <83mulin7ui.fsf@gnu.org> <83k1gmn6b2.fsf@gnu.org> <83imw6n4ny.fsf@gnu.org> <20190326205716.GC6837@adacore.com> <83imw5kn1n.fsf@gnu.org> <20190327125603.GA12551@adacore.com> From: Simon Marchi Message-ID: <8b7719b7-93e1-5833-f350-54ec0af83dcc@simark.ca> Date: Sat, 30 Mar 2019 17:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190327125603.GA12551@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-03/txt/msg00763.txt.bz2 On 2019-03-27 8:56 a.m., Joel Brobecker wrote: >>> This is going to be one more manual test to do after each branch, >>> and I'm a bit concerned about that. We can start with that, as we want >>> the test to pass. But I'm wondering if, instead of getting the output >>> from "show version" to determine the expected values, we could parse >>> gdb/version.in instead. If needed, we could so the parsing as part of >>> the build process (ig do it in the makefile, and store the result in >>> a couple of files). Something like that. >> >> Yes, if version.in is updated by some automated method, the same >> method could update the test suite. > > We're actually thinking of getting rid of that daily bump, and doing > this would make it more difficult. There has to be a way to parse > version.in during the build and make that information available to > the testsuite, somehow. If not, I'd rather adjust the testing to > allow regexps, and just verify that it prints a positive number for > the major version, and a non-zero number for the minor version. > I wrote a patch to make the test read the version number from version.in directly, see here: https://sourceware.org/ml/gdb-patches/2019-03/msg00762.html Simon