Re: Problems building coreutils HEAD against gnulib HEAD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [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. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHutmD84KuGfSFAYARAj+JAKCks8FiZ1bXzsLQu0y1YY3w7fPzygCgyxj5 CuMXB3YbUD4i+7UYeO12S34= =5pMJ -END PGP SIGNATURE-
Re: Problems building coreutils HEAD against gnulib HEAD
Eric Blake [EMAIL PROTECTED] 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 21 + # Reconfigure, getting other files. for command in \
Re: Problems building coreutils HEAD against gnulib HEAD
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
Re: Problems building coreutils HEAD against gnulib HEAD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Andreas Schwab on 2/19/2008 8:37 AM: | Jim Meyering [EMAIL PROTECTED] writes: | | +# 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 21 | | Why do you need -depth? Also, find 4.1 does not support -L nor -delete. Because -delete implies -depth, and new enough findutils warns and does nothing rather than deleting a possibly different set of files than what you tested with (the use case that prompted the change was something like find -name '*.txt' as the dry run, then find -delete -name '*.txt' which proceeded to delete everything in `.'). | A more portable predicate is -xtype l. The goal here is not to delete all symlinks, just symlinks that are broken. Under the influence of -L, does -xtype l work like -lname '*' in detecting just the broken symlinks? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHuzgX84KuGfSFAYARAlCmAKDUxWGgIJ8Vy9QxRLbSXf4JdCPvmwCgmgV6 Rb+jT8xFrKlHjTxs0YRM4h4= =Dp4r -END PGP SIGNATURE-
Re: Problems building coreutils HEAD against gnulib HEAD
Jim Meyering [EMAIL PROTECTED] writes: +# 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 21 Why do you need -depth? Also, find 4.1 does not support -L nor -delete. A more portable predicate is -xtype l. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Problems building coreutils HEAD against gnulib HEAD
On Feb 19, 2008 8:12 PM, Eric Blake [EMAIL PROTECTED] wrote:
The goal here is not to delete all symlinks, just symlinks that are
broken. Under the influence of -L, does -xtype l work like -lname '*' in
detecting just the broken symlinks?
For that you want find . -depth -type l -xtype l -delete. That is,
a broken symbolic link looks like a link to both a physical and a
logical view. To do the same thing with 4.1.7, use find . -depth
-type l -xtype l -exec /bin/rm -f {} \; though in this case the
-depth is not really needed.
James.
