[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC 00/10] Enable repository wide style checking
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [PATCH RFC 00/10] Enable repository wide style checking |
Date: |
Fri, 14 Aug 2015 10:57:05 +0100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Thu, Aug 13, 2015 at 09:39:48PM +0100, Peter Maydell wrote:
> On 13 August 2015 at 19:27, Eric Blake <address@hidden> wrote:
> > It's worth asking the gnulib folks for an opinion on whether relaxing
> > the license on maint.mk and GNUmakefile to explicitly go back to GPLv2+,
> > and/or explicitly add some explicit exception clause like gcc that makes
> > it clear that using these files to build does not taint the built
> > product. Personally, I see no problem with using GPLv3'd tools (after
> > all, qemu requires GPLv3 GNU make, and gcc is also GPLv3 although clang
> > can step around that one), but I also see your reluctance of even having
> > a file in the qemu.git repo that has a GPLv3 clause.
>
> Right; we don't ship make or gcc in our code repo, and using
> external-to-the-repository tools which happen to be GPLv3 is
> obviously fine. Similarly, if you used the maint.mk script externally
> as a tool which allowed you to find bugs which you submitted
> patches to fix that wouldn't be a problem. I just don't want
> a GPLv3-licensed file in the git repo and an integrated part
> of our build-and-test system...
Ok, I certainly understand why we can't have GPLv3 code built
into QEMU, but I thought build-system tests would be ok because
it does not affect the built binaries in any way.
> I would certainly appreciate a maint.mk with a GPLv2-or-later
> license. Our other options are (a) use the last v2+ version
> (which is what we do with our binutils disassemblers)
> (b) do the style checks we care about some other way or
> (c) don't bother doing the style checks at all.
Option (b) could involve re-factoring the existing check_patch.pl
script to give us the 2 main benefits from the gnulib check code
- Ability to turn on/off individual rules on a per-file basis
- Ability to run against the entire codebase not just patches
IIUC, the check_patch.pl script was imported from Linux, so I'm
not sure if there is a general desire to minimize the divergance
from the original file, or whether refactoring would be welcome ?
I can certainly explore the viability of such an approach if people
are conceptually open to some significant changes to check_patch.pl
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|