[PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

Pedro Alves palves@redhat.com
Thu Aug 4 22:37:00 GMT 2016


On 07/31/2016 11:50 PM, Manuel López-Ibáñez wrote:

> Oh well, Ayush does not have access to different hosts, thus I
> guess it is better that he focuses his limited time on functions that
> he can test. There are plenty of functions that are both in gnulib and
> libiberty but not in glibc.
> 

My experience on the gdb side is that these kinds of patches tend
to move much faster if there's confidence they got wide host testing.  

I'm not a gcc maintainer, but I'd suggest:

 - Put the patches on a public branch (e.g., a personal branch in
   the gcc git mirror), and point at the branch in patch
   submissions.  A branch is easier for the occasional passerby testing
   than downloading a patch and then curse a bit while trying to
   to figure out the base revision the patch was generated against, because
   it no longer applies cleanly on current trunk.

 - Explicitly call for testing help, pointing at the branch.  This makes
   it possible for a global maintainer to reasonable call a timeout.
   As in, "as we've called for testing X ago, and clearly nobody cares,
   let's go ahead, and fix any fall out afterwards.")

 - Get access to the gcc compile farm and go the extra mile of testing
   the patches on a couple non-GNU/Linux hosts.  For example, there are
   AIX and NetBSD boxes there.  I sometimes do this on the gdb side,
   and it helps much with moving things along.

 - Still on the extra mile theme, install cross compilers, and
   cross build gcc for those.  For example, Fedora has a mingw-w64
   toolchain in the main repo, which makes it's easy to at least
   cross build for Windows.

Thanks,
Pedro Alves



More information about the Gcc-patches mailing list