Hello, * Eric Blake wrote on Tue, Feb 19, 2008 at 02:28:35PM CET: > [adding bug-automake] > > According to Jim Meyering on 2/19/2008 4:33 AM: > |> But I am, having seen it myself. It happens when you have a stale symlink > |> from an older copy of gnulib, but which now points nowhere because the > |> file was renamed in gnulib. > | > | It's annoying. Didn't someone (you, Eric?) post an automake > | patch to generate Makefile rules that would avoid this? > > You are thinking about this patch of Ralf's: > http://git.sv.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=d0ebf71 > > I'm not sure if that was ported back to the 1.10 branch. But it looks > like that patch only handles the make rules for rerunning aclocal, and > will not impact the ./bootstrap rules for running aclocal afresh when > there are broken symlinks matching *.m4 in the included directories. > Maybe one more automake patch is needed, to avoid warning on broken > symlink source files
I don't think aclocal should silenctly ignore stale symlinks. I can't imagine a situation in which I wouldn't call stale symlinks a bug in another program, or a mistakenly broken tree. > if the resulting aclocal still manages to provide > every needed macro? Well, aclocal cannot easily detect whether you intended for that local pkg/gnulib/m4/foo.m4 macro to override that installed /usr/share/aclocal/foo.m4 macro file or not. I prefer if such issues do not go silent in any cases we can avoid. > Meanwhile, I still think coreutils' bootstrap should > delete these broken symlinks before trying to run aclocal. I think that's just the proper solution to this issue. And with Automake master, it should also not cause hickups any more. Cheers, Ralf _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils