[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems building coreutils HEAD against gnulib HEAD
From: |
Jim Meyering |
Subject: |
Re: Problems building coreutils HEAD against gnulib HEAD |
Date: |
Tue, 19 Feb 2008 16:05:33 +0100 |
Eric Blake <address@hidden> wrote:
> [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 if the resulting aclocal still manages to provide
> every needed macro? Meanwhile, I still think coreutils' bootstrap should
> delete these broken symlinks before trying to run aclocal.
I agree.
What do you think of this patch (untested)?
It's probably good enough, but I'll bet someone will
suggest a more portable version :-)
diff --git a/bootstrap b/bootstrap
index 7dacfe6..1dd3bc2 100755
--- a/bootstrap
+++ b/bootstrap
@@ -2,7 +2,7 @@
# Bootstrap this package from checked-out sources.
-# Copyright (C) 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
+# Copyright (C) 2003-2008 Free Software Foundation, Inc.
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -538,6 +538,12 @@ if test -f $mam_template; then
done
fi
+# Remove dangling symlinks in gnulib-populated directories.
+# This depends on GNU find, and a relatively recent version at that.
+# Ignore any failure for now, since it's only to avoid the relatively
+# unusual case in which a symlinked-to file in gnulib/ or gl/ is removed.
+find -L m4 lib build-aux -depth -lname '*' -delete > /dev/null 2>&1
+
# Reconfigure, getting other files.
for command in \
- Re: Problems building coreutils HEAD against gnulib HEAD, Eric Blake, 2008/02/19
- Re: Problems building coreutils HEAD against gnulib HEAD,
Jim Meyering <=
- Re: Problems building coreutils HEAD against gnulib HEAD, Andreas Schwab, 2008/02/19
- Re: Problems building coreutils HEAD against gnulib HEAD, Eric Blake, 2008/02/19
- Re: Problems building coreutils HEAD against gnulib HEAD, James Youngman, 2008/02/19
- Re: Problems building coreutils HEAD against gnulib HEAD, Andreas Schwab, 2008/02/19
- Re: Problems building coreutils HEAD against gnulib HEAD, Eric Blake, 2008/02/20
- Re: Problems building coreutils HEAD against gnulib HEAD, Jim Meyering, 2008/02/20
Re: Problems building coreutils HEAD against gnulib HEAD, Ralf Wildenhues, 2008/02/19