Eric Blake <[EMAIL PROTECTED]> writes: > Simon Josefsson <simon <at> josefsson.org> writes: > >> > The 'gnumakefile' in particular does not provide functionality to the user >> > of the package, only to the maintainer. It does not change the way "make" > and >> > "make check" work. It has no test suite. Therefore it doesn't make much > sense >> > to include it in --create-testdir. >> >> It seems the patch isn't enough, the infloop still happens. The reason >> seems to be that maintainer-makefile is not filtered out, and it depends >> on gnumakefile. > > Does it help if you change Bruno's patch to filter on git-version-gen, rather > than on gnumakefile?
Yes, the code in GNUmakefile first tests if git-version-gen is there before proceeding, so it would solve it. That may be a cleaner fix than filtering out gnumakefile. >> I'm not sure these gnulib-tool hacks are the right solution though. It >> seems to me like it would be useful to make GNUmakefile more robust, and >> having it fail more gracefully when a .tarball-version file is missing. >> But I don't care strongly about it. > > Again, it is not GNUmakefile that is wrong, it is the fact that you are > including git-version-gen but violating the requirements of git-version-gen. > It is only when build-aux/git-version-gen exists that GNUmakefile then > expects > that you are either in a VCS tree or that .tarball-version exists. I'm just running 'gnulib-tool --create-testdir --with-tests --dir=foo' which I think should be robust regardless of what quirks specific modules have. /Simon
