Re: Generate package.m4 in build-dir, not srcdir.

[Ralf Wildenhues]

* 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