Re: Problems building coreutils HEAD against gnulib HEAD

[Ralf Wildenhues]

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