severity 12064 minor thanks On 07/27/2012 04:12 AM, Peter Johansson wrote: > Hi automakers, > > I was about to make a release when I discovered that distcheck suddenly > didn't work > anymore. The distclean rule failed with > > Making distclean in doc > make[2]: Entering directory > `/home/peterJo/projects/software/yat-0.8.x/yat-0.8.2/_build/doc' > Makefile:498: ../yat/classifier/doxygen.mk: No such file or directory > Makefile:499: ../yat/normalizer/doxygen.mk: No such file or directory > [Aside: This seems quite a complex and brittle occurrence of inter-directory dependencies; have you thought about the possibility of converting to a non-recursive setup? I have done so with Automake itself (since version 1.12), and have been very, very happy with that move so far.]
> This was for a stable branch release so there had just been minor changes in > two .cc files > and no changes at all wrt the build system. After some investigation I found > that Automake > 1.12.2 has changed the order directories are traversed for clean rules. > I thought of this change as a mere cleanup actually, since the previous different order of directory traversal for clean rules was basically a relic needed by the older (and now long-dead) implementation of automatic dependency tracking: <http://www.gnu.org/software/automake/history/automake-history.html#First-Take-on-Dependencies> > I must say I find > it unexpected that behaviour like this is changed between 1.12.1 and 1.12.2. > I thought this > kind of changes were only introduced when bumping versions from say 1.11 to > 1.12 and not > between stable releases. > > The reason I got the failure is that files doxygen.mk are included into > doc/Makefile. > These files are generated in the corresponding Makefile and listed under > DISTCLEANFILES > so they are deleted during 'make distclean'. As SUBDIRS in top Makefile.am is > "SUBDIRS = doc yat" that was not a problem before since doc was entered first > during > cleaning and doc/Makefile was already gone when the doxygen.mk files were > removed. > > Perhaps a strange use case, but still I wanted to report it. > And you did well; perhaps this this worth some documentation addition? Not sure. Anyway, a good reason to keep the bug report open for now. > I think I've found a workaround > Curios: which workaround? > so I can get out the release without needing to > downgrade Automake. > > Thanks, > Peter > Regards, Stefano