Re: yaccvpath.test

[Pavel Roskin]

Hello, Tom!

Thank you for your answers! When I asked them I didn't realize that the
point of yaccvpath.test was not failed "make distcheck", but an
out-of-date file appearing in the tarball.

Anyway, I'm glad to see that our views are very similar.

> Pavel> 1) "make dist" must ensure that out-of-date generated
> Pavel> distributable files (parser.c, Makefile.in etc) are not
> Pavel> included in the tarball either by running "make all" or
> Pavel> otherwise. Yes or no?
>
> Yes.  This has been on the to-do list for a long time.
> I don't recall what has been holding it up.

I do misuse this shortcut ("make dist" before "make all") but I know what
I'm doing, which may not be the case for other people. I'm ready to accept
some personal inconvenience in exchange for the better quality of software
using Automake :-)

> Pavel> 2) "make distcheck" must ensure that out-of-date generated
> Pavel> distributable files are not included in the tarball by exiting
> Pavel> with non-zero code. Yes or no?
>
> It would be nice but this is probably very hard, since the user can
> add random targets to build just about anything.

This is reasonable since you answer "yes" to the first question. "make
all" should guarantee it and "make dist" should rely on it.

> Pavel> 3) Out-of-date generated distributable files should be
> Pavel> recreated in the build directory. Always, never, only when no
> Pavel> write permissions for srcdir?
...
> For yacc/lex output the answer probably depends on what the user wants
> to happen.  For instance you might have one answer for the developer
> and another answer after unpacking a `dist' tarball.

If we need it with the `dist' tarball it's a big problem with that
tarball. I won't mind a failure at this point.

I like you approach to do "what the user wants", I just don't see a
situation where anybody would want to create a file in builddir instead of
overwriting it in srcdir (or attempting to do so with a subsequent
failure).

> Pavel> 4) "make distclean" should attempt to clean generated
> Pavel> distributable files that appear in the build directory. Yes or
> Pavel> no?
>
> Yes.  `make distclean' must leave the build directory as it was before
> configure.  When `make distcheck' is failing in this test it is
> because distclean is not properly doing its job -- in a fresh build
> directory `configure ; make ; make distclean' must leave the directory
> empty.

I know what `make distclean' is supposed to do. Not creating distributable
files in the build directory would releave us from cleaning them there.

Regards,
Pavel Roskin