Re: [Qemu-devel] [PATCH] build-sys: generate tests/.gitignore

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

On 09/05/2017 05:42 AM, Marc-André Lureau wrote:
> 
> I understand the feeling, I do also mostly out of tree build. However, I
> don't think it makes much sense to generate .gitignore in the build dir.
> It's git related, and in the git source dir, you have .git that is writable
> already: it'd be odd that the git wortree/srcdir is read-only, and the
> point is to generate .gitignore. Not so true with tarballs though.
> 
> I wrote this patch inspired by how the
> https://github.com/behdad/git.mk/blob/master/git.mk rules does it (it is
> uses by many GNOME projects and others with autoconf). The way it gets away
> with not touching the srcdir in non-git tree, is that the git.mk file is
> not shipped in distributed tarball. We could have a similar approach if
> necessary.

Shipping .gitignore in the tarball is not necessary; it's main benefit
is for in-tree development.

> 
> Another alternative, which I find much less appealing, is that qemu tree
> keeps shipping .gitignore, and we just add a manual rule to maintain it.

Keeping .gitignore in git, if it is generated, is a pain, because then
we have to manually resync it every time it gets out of date (and we're
already demonstrating that we forget to update .gitignore with new
tests).  This patch is only worthwhile if it reduces maintainer
overhead, but not if it trades one task for another.

> 
> You suggested using more test* *test etc wildcards. I think this is bad, I
> would rather have a precise .gitignore, and not ignore extra files that are
> not part of the build-system. I couldn't find a simple way to generate
> precise rules for intermediary files (like .o etc), but for end targets,
> this patch demonstrates it can be done quite easily.
> 
> Finally, there is this trend these days with meson to not even allow
> in-tree build, and thus no need for .gitignore..

Please don't go the direction of forbidding in-tree builds.  While I am
a BIG fan of VPATH builds, I'm also a big fan of in-tree builds (it's
slightly faster to do a one-off in-tree build of a fresh git checkout
than it is to set up yet another VPATH build directory).  Projects that
force one way or the other are annoying.  I see no reason why we should
not keep both approaches working, particularly if we have patchew or
other automation that covers both styles.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]