bug#7819: automake does not really automatically distribute all the files it's advertised to.

[Ralf Wildenhues]

* Stefano Lattarini wrote on Mon, Jan 10, 2011 at 10:40:13PM CET:
> On Monday 10 January 2011, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Mon, Jan 10, 2011 at 08:50:13PM CET:
> > > But the above is not always correct, as some of these files are 
> > > distributed
> > > *only* if other conditions are met.  For example, acconfig.h and 
> > > aclocal.m4
> > > are distributed only if they really exists at automake runtime (having 
> > > them
> > > as targets in Makefile.am won't work),

I didn't fully realize this when reading it last time.  That's an ugly
inconsistency.  :-/  Luckily most of these are typically not generated
only after automake (still; see e.g., ChangeLog, THANKS, in coreutils).

More generally though, I get suspicious for any external stuff which
influences the result of 'automake', because it makes writing rebuild
rules harder or impossible.  These automatically-distributed files can
cause build or distribution problems for projects which embed optional
subprojects (and try to share files, for example).  There has been a
report to this end not too long ago, I think, but we've seen more than
just one.

But even just having a distribution "magically" fixed by rerunning
'automake' (after all files are in place) is very unintuitive, and
has been source for questions from users.

> > Agreed.  With many of the names, I have been wondering though whether we
> > should distribute them at all in arbitrary directories.  For example,
> > most scripts don't make that much sense outside of the toplevel or the
> > build-aux directories.
> >
> Ouch.  I thought that the files listed above were distributed only when
> found in the top-level directory, but now I see that they are in fact
> distributed if found in the same directory of the being-processed
> Makefile.am (and this is even documented, albeit not very clearly).
> 
> Maybe we should deprecate this behaviour in the manual, add an XFAILing
> testcase, and change the behaviour after the next release.  But then
> you say ...
> 
> > Then again, changing the current behavior here is quite likely to break
> > some existing package setups, and even silently and only upon 'make
> > dist' (so it might never show up for the developer), so that I'm not
> > inclined to change this lightly.
> >
> Oh, OK.  Your call -- I won't push you in any direction about this issue.

Well, I must confess I'm not totally sure on this one.  For the
documentation files (README, ChangeLog, ...) it would probably make
sense to do so though.  Hmm.

Cheers,
Ralf