From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1882 invoked by alias); 27 Mar 2019 12:56:08 -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 1852 invoked by uid 89); 27 Mar 2019 12:56:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=daily X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 27 Mar 2019 12:56:07 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 9E3FF116D73; Wed, 27 Mar 2019 08:56:05 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sbjVuT-Fx7bj; Wed, 27 Mar 2019 08:56:05 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 6D027116D6F; Wed, 27 Mar 2019 08:56:05 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id B50AE83AE0; Wed, 27 Mar 2019 05:56:03 -0700 (PDT) Date: Wed, 27 Mar 2019 12:56:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: simark@simark.ca, gdb-patches@sourceware.org Subject: Re: GDB version as convenience variable Message-ID: <20190327125603.GA12551@adacore.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83imw5kn1n.fsf@gnu.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2019-03/txt/msg00637.txt.bz2 > > 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. -- Joel