On 01/04/2018 07:49 PM, Mathieu Lirzin wrote: > for example from Automake 1.15.1 build directory the following command > is supposed to work: > > --8<---------------cut here---------------start------------->8--- > $ t/wrap/automake-1.15 --vers > automake (GNU automake) 1.15.1 > Copyright (C) 2017 Free Software Foundation, Inc. > License GPLv2+: GNU GPL version 2 or later > <http://gnu.org/licenses/gpl-2.0.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Written by Tom Tromey <tro...@redhat.com> > and Alexandre Duret-Lutz <a...@gnu.org>. > --8<---------------cut here---------------end--------------->8--- > > According to your logs this doesn't work on your system. My impression > is that those failing tests are checking the edge cases of Getopt::Long > which is system dependent and not the functional behavior of Automake. > As a consequence it seems reasonable to narrow the tests to more > conservative Getopt::Long behaviors. > > WDYT?
If I understand GNU Coding Standards, we really do want to make sure unambiguous abbreviations of long options work. I'd argue that if not all versions of perl Getopt::Long are working the way the testsuite currently expects, that we should instead keep the test unchanged and find ways to work around the broken perl module versions (perhaps by manually specifying all abbreviations as explicit options ourselves, rather than relying on Getopt::Long to do it for us). At the same time, once we do ascertain which version of Getopt::Long you are using, it may be worth reporting the flaw in that version to your distro vendor, as Automake is not the only software that would have to work around that particular weakness. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
