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 <pbonz...@redhat.com> >> --- > >> +++ 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 <http://www.gnu.org/licenses/>. > > 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
