GNU bug report logs -
#7819
automake does not really automatically distribute all the files it's advertised to.
Previous Next
Full log
Message #20 received at 7819 <at> debbugs.gnu.org (full text, mbox):
* 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
This bug report was last modified 13 years and 336 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.