* Jim Meyering wrote on Sun, Nov 11, 2007 at 05:57:45PM CET: > > However, we expect developers to have reasonable tools, > including GNU make.
Hmm. Yes, on my systems that is the case. But I avoid GNU make on systems I run tests on. So far I've done that because I thought we aimed at portable 'make'. Mostly those systems work off of a tarball though. > Do you typically do non-srcdir builds? Yes. I typically never do in-srcdir builds. > Maybe that's the difference? Looks like it. > > FWIW, I can't get the current tree to pass test 13 (and others) with any > > combination of `rm -rf autom4te.cache', `autoreconf -vi', or --force > > added, PATH pointing to $buildtree/tests first, whatever: > ... > Yes, I've noticed that, too. > It's rather annoying, but the temporary work-around is simply to > run "make clean", then make test. Hmm. It seems that helped the test failures. I'll try to check that next time I see the failure. > > FWIW, I posted a patch to fix the package.m4 build here: > > http://lists.gnu.org/archive/html/autoconf-patches/2007-11/msg00028.html > > I did see that, but doesn't it just paper over the real problem: > missing dependencies? No, why? It depended on `Makefile' there. > I think we can do better. > > See also > > http://lists.gnu.org/archive/html/autoconf-patches/2007-11/msg00032.html > > > > Also, I don't like the fact that we can't eat our own dog food in that > > we advertise in the manual generation of package.m4 differently than we > > do it ourselves. > > Well, users of autoconf can be expected to run a single > version of autoconf, while autoconf developers have a moving > target: the current version, with a potentially-just-updated > version number, and the previous version, which probably generated > many of the files in the build directory. So the problems here > are unique to the autoconf-dev's build process. There's no need to > worry about this dichotomy. IMHO, it's not an issue of dog-food, > since the situations are fundamentally different. OK. > > propose a patch that will just autoreconf the tree on every git > > version change. That would solve the package.m4 issue as a by-product. > > But that's what happens already, via GNUmakefile, and it's not enough... > due to missing dependencies. Hmm, I assume I should cd $top_builddir; ln -s $srcdir/GNUmakefile would that help? If yes, how about adding AC_CONFIG_LINKS([GNUmakefile:GNUmakefile]) to configure.ac (and fixing Makefile.maint:ME to include $(srcdir))? Cheers, Ralf
