From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gSUQ1-0001Zz-Gv for qemu-devel@nongnu.org; Thu, 29 Nov 2018 17:04:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gSUPx-00022u-0e for qemu-devel@nongnu.org; Thu, 29 Nov 2018 17:04:21 -0500 Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]:38831) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gSUPw-00022B-Q8 for qemu-devel@nongnu.org; Thu, 29 Nov 2018 17:04:16 -0500 Received: by mail-wm1-x343.google.com with SMTP id k198so3797255wmd.3 for ; Thu, 29 Nov 2018 14:04:16 -0800 (PST) Sender: Paolo Bonzini References: <1543513531-1151-1-git-send-email-pbonzini@redhat.com> <1543513531-1151-3-git-send-email-pbonzini@redhat.com> <8518998d-f79b-8478-ceb8-23cb7b3c1cb0@redhat.com> From: Paolo Bonzini Message-ID: <0a0b4592-791e-716c-5adf-c4f9c946c2c7@redhat.com> Date: Thu, 29 Nov 2018 23:04:11 +0100 MIME-Version: 1.0 In-Reply-To: <8518998d-f79b-8478-ceb8-23cb7b3c1cb0@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 2/2] test: replace gtester with a TAP driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, berrange@redhat.com On 29/11/18 22:06, Eric Blake wrote: > On 11/29/18 11:45 AM, Paolo Bonzini wrote: >> gtester is deprecated by upstream glib and it does not support tests >> that call g_test_skip in some glib stable releases. >> >> glib suggests instead using Automake's TAP support.  We do not support >> Automake, but we can copy the code that beautifies the TAP output and >> use it.  I chose to use the Perl copy rather than the shell/awk one, >> in order to reuse Perl's TAP parsing package, but I'm open to suggestions >> about which language to use. > > Maybe a reference to a URL documenting the glib deprecation would be in > order? I found https://blog.gtk.org/2018/07/11/news-from-glib-2-58/ Good idea. >> Signed-off-by: Paolo Bonzini >> --- > >> +++ b/scripts/tap-driver.pl >> @@ -0,0 +1,386 @@ >> +#! /usr/bin/env perl >> +# Copyright (C) 2011-2013 Free Software Foundation, Inc. > > This is not the latest version of automake.git/contrib/tap-driver.pl - > which Automake version is it from?  Automake moved its perl driver out > to pasture in 2013, stating that the awk+shell version is preferred in > new automake projects.  I don't have a strong preference for which one > you pick, but do worry that if automake adds future enhancements to the > awk+shell, then the perl version won't keep up and we'll be stuck > redoing things again in a few years.  On the other hand, TAP doesn't > seem to be gaining new features at a very fast rate. It does get some new features from time to time, and that's why I preferred an external parser to a home-grown one---especially if we would need to duplicate the awk parser in tap-merge.pl. The version I used is just the one in the machine where I developed it (RHEL 7), but there have been no relevant changes after that commit, so it's not important. >> +# You should have received a copy of the GNU General Public License >> +# along with this program.  If not, see . > > Among other things, the most recent version of tap-driver.pl switched > all references to https://. I can change this too. >> +# As a special exception to the GNU General Public License, if you >> +# distribute this file as part of a program that contains a >> +# configuration script generated by Autoconf, you may include it under >> +# the same distribution terms that you use for the rest of that program. > > We do not use Autoconf, so this exception does not apply to our use of > this file.  But since our project is GPL, I don't see including this > file as a problem, nor do I find any problem with leaving the exception > in place. Yes, I find removing exceptions to be a bit unkind. Paolo