gnulib-tool has done hard-linking for testdirs since the beginning, but it has
more drawbacks than advantages:
* When I am building a testdir and doing unrelated changes in my gnulib
checkout at the same time, especially on the .m4 files, it will trigger
a reconfiguration of the testdir, which takes a long time.
* When I edit a file in the testdir using 'vi', the change gets propagated
back to the gnulib checkout. But it does not do so with 'emacs' or 'kate'
as editor. So, if you see this as a feature, it's only a partially
implemented
feature.
* When I transport two different testdirs to a different machine through a
single .tar.gz file, the hardlinks are still preserved on the other machine
(even on Windows, with Cygwin!). The effect is that if I make a test change
in one of the testdirs, the other testdir is affected as well - which is
usually undesired.
2017-05-20 Bruno Haible <br...@clisp.org>
gnulib-tool: Don't create hard links between gnulib and its testdirs.
* gnulib-tool (func_create_testdir): Don't invoke 'ln'.
diff --git a/gnulib-tool b/gnulib-tool
index f3463b6..c5b993a 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -6084,7 +6084,6 @@ func_create_testdir ()
if test -n "$lookedup_tmp"; then
cp -p "$lookedup_file" "$testdir/$g"
else
- ln "$lookedup_file" "$testdir/$g" 2>/dev/null ||
if func_should_symlink; then
func_ln "$lookedup_file" "$testdir/$g"
else
