[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: automake 1.6.3: make distcleancheck too finicky
From: |
Alexandre Duret-Lutz |
Subject: |
Re: automake 1.6.3: make distcleancheck too finicky |
Date: |
15 Sep 2002 20:50:03 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>> "Karl" == Karl Berry <address@hidden> writes:
Karl> In automake 1.6.3, make distcleancheck actually fails if there are files
Karl> left after distclean:
Karl> ERROR: files left after distclean:
This would be better diagnosed as
`files left _in the build tree_ after distclean'
since it covers two kinds of errors:
1. files that are forgotten by distclean;
2. files that are erroneously rebuilt.
Karl> ./doc/info.1
Karl> ./doc/install-info.1
Karl> ./doc/makeinfo.1
Karl> ./doc/texindex.1
Karl> ./info/funs.h
Karl> ./info/doc.c
Karl> ./info/key.c
Karl> make[1]: *** [distcleancheck] Error 1
Karl> This seems too restrictive to me. I *want* to include those files in
Karl> the distribution, even though they are generated.
So you are in case #2. Why are these distributed files
rebuilt, even out of a freshly unpacked tarball?
(distributed files are expected to be up-to-date)
Karl> That way, if something goes wrong with the generation,
Karl> the installer can still get their job done without
Karl> reproducing the entire development environment.
Karl> And the man pages might be nice to see before installing.
That the generation is fragile seems a good argument in favor of
trying hard to fix this man-pages-always-rebuilt issue.
>From now on, I'll assume you have a dependency like
`foo.1: foo$(EXEEXT)' in your Makefile.am. This would
be enough to explain why `foo.1' is always rebuilt: it
depends on a non-distributed built file.
In fact you don't really want to rebuild `foo.1' each time
`foo$(EXEEXT)' is rebuilt. Actually `foo.1' should only be
updated each time foo's --version or --help outputs change.
Assuming foo.c is the source of the help message and configure.ac the
source of the version string, you could use a rule similar to
foo.1: $(srcdir)/foo.c $(top_srcdir)/configure.ac
$(MAKE) foo$(EXEEXT)
$(HELP2MAN) --output=$@ foo$(EXEEXT)
This rule won't be triggered in a freshly unpacked tarball, and
consequently you don't have to wonder about users that don't
have help2man.
Karl> (Seems like every distribution that uses help2man would have this
Karl> problems, unless they don't distribute the man pages.)
See Autoconf and Coreutils. Both use a rule similar to the
above (without the `$(MAKE) foo' step, because they expect the
binaries to be built by the time the man/ subdirectory is
processed).
Karl> Perhaps it would be possible to not complain about files that are
Karl> included in the dist that are left after make distclean. That would
Karl> probably be the cleanest solution.
This would hide other bugs related to broken dependencies.
We really want to detect distributed files that depend upon
non-distributed built files.
--
Alexandre Duret-Lutz