* 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