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

[Jim Meyering]

Ralf Wildenhues <address@hidden> wrote:
> * Jim Meyering wrote on Sat, Nov 10, 2007 at 10:36:06PM CET:
>> I don't know why the current code tries to build package.m4
>> in $(srcdir), but it fails when $(srcdir) is read-only, and
>> it appears to be unnecessary.
>
> Because that generates no end of hassles, and IMHO we're right into
> those hassles right now.
>
> Golden rule: put stuff that you distribute in srcdir.  Put stuff that
> you don't distribute in builddir.  Do not create stuff with
> config.status that you distribute.
>
> We've had troubles with VPATH issues in Libtool without end until we
> _just followed_ that rule.  Not all make are GNU make.

Which case are you concerned about?
Building from a distribution tarball?  In that case,
of course, everything must be absolutely perfect,
and work with any manner of crufty build environment.

However, we expect developers to have reasonable tools,
including GNU make.

Do you typically do non-srcdir builds?
Maybe that's the difference?

> 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.

> If you need more info, please ask, because I'm not going to fix it right
> now.
>
> 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?  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.

> I am getting a bit tired of these issues.  Next time I'm going to

Sorry it's frustrating for you.

> 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.

I'll try to find time soon.