From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103760 invoked by alias); 12 Mar 2019 17:23:39 -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 103747 invoked by uid 89); 12 Mar 2019 17:23:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: mail-wr1-f54.google.com Received: from mail-wr1-f54.google.com (HELO mail-wr1-f54.google.com) (209.85.221.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Mar 2019 17:23:38 +0000 Received: by mail-wr1-f54.google.com with SMTP id 33so1096699wrb.13 for ; Tue, 12 Mar 2019 10:23:37 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id f1sm1882054wmh.44.2019.03.12.10.23.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Mar 2019 10:23:35 -0700 (PDT) Subject: Re: [pushed 0/2] Fix test-cp-name-parser build To: Tom Tromey References: <20190312170327.14109-1-palves@redhat.com> <87k1h43to0.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <322a3b37-e134-e6e7-92b5-aa900c337fc6@redhat.com> Date: Tue, 12 Mar 2019 17:23:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87k1h43to0.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-03/txt/msg00248.txt.bz2 On 03/12/2019 05:10 PM, Tom Tromey wrote: > Pedro> I'm pondering what could we do to avoid these kinds of regressions. > Pedro> We could make the buildbot always build these utilities too. Maybe > Pedro> even better, add some testsuite testcase that smoke-tests > Pedro> test-cp-name-parser. > > We could migrate this to use the unit test framework and just not have a > separate executable. Oh that might be even better, indeed. I recall using the executable for quick experimentation when I was working on the wildmatching stuff, but I think hacking in a unit test for experimentation would have worked well enough too. Thanks, Pedro Alves