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

[Stefano Lattarini]

On Monday 10 January 2011, Ralf Wildenhues wrote:
> Hi Stefano,
> 
> * Stefano Lattarini wrote on Mon, Jan 10, 2011 at 08:50:13PM CET:
> >   Files which are automatically distributed, if found:
> >     ABOUT-GNU           README              config.rpath        ltcf-gcj.sh
> >     ABOUT-NLS           THANKS              config.sub          ltconfig
> >     AUTHORS             TODO                configure           ltmain.sh
> >     BACKLOG             acconfig.h          configure.ac        mdate-sh
> [...]
> >   ...
> > 
> > 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), config.h.bot and config.h.top are
> > distributed only if the AC_CONFIG_HEADERS macro is used, and stamp-vti is
> > distributed only if info_TEXINFOS and version.texi are used.
> > 
> > So, either the automake script or the automake help screen should be
> > adjusted.
> > 
> > IMHO the current behaviour of automake is good enough, so I think we
> > should adjust the automake help screen to read something like:
> 
> 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.

> Documenting the existing behavior better sounds like a good idea to me.
>
> Thanks for the report,
> Ralf
> 

Thanks,
   Stefano