bug-automake
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]