Discussion:
gnulib build/test ?
Tim Rühsen
2017-05-16 11:13:05 UTC
Permalink
Hi,


I just git cloned gnulib to work on certain bugs.

Not sure how to build and run the test suite. The README just points me
to a .texi file which is hardly readable, at least I get a headache
after ~10s.


doc/README... something about web pages.


I tried 'make' - nothing happened.

'make check' fails
Makefile:142: recipe for target 'sc_check_copyright' failed
make: *** [sc_check_copyright] Error 1

Looking into Makefile... nothing helpful

user.txt... nothing helpful

No 'bootstrap' or similar scripts that 'sounds right'.


What else should I try to build + run the test suite ?


With Best Regards, Tim
Bruno Haible
2017-05-16 13:17:53 UTC
Permalink
Hi Tim,
Post by Tim Rühsen
Not sure how to build and run the test suite. The README just points me
to a .texi file which is hardly readable, at least I get a headache
after ~10s.
I agree. The README should better say to
$ cd doc
$ make gnulib.html
$ xdg-open gnulib.html
or read the manual at
https://www.gnu.org/software/gnulib/manual/gnulib.html
Post by Tim Rühsen
What else should I try to build + run the test suite ?
You first pick a subset of the Gnulib modules, that you want to work on.
Then you create a testdir for these modules:

$ ./gnulib-tool --create-testdir --dir=../testdir1 --single-configure MODULE1 [MODULE2...]

This testdir is something you can "./configure CPPFLAGS=-Wall && make && make check".

For the set of Gnulib modules:
- If you don't specify any, it defaults to *all*!
- There is a script 'posix-modules' that returns the POSIX related modules. Use like this:
$ ./gnulib-tool --create-testdir --dir=../testdir-posix --single-configure `./posix-modules`

Note the difference between --dir=../testdir1 and --dir=/tmp/testdir1 : The former is on the
same file system as the gnulib checkout, and uses hard links to the .c and .h files; therefore
for quick edits of only .h and .c files you can do the edits in the testdir, test them
through "make" and "make check", and will usually find them present in the gnulib clone.
In the second case, or when you start to edit .m4 files or module descriptions, it's useful
to work in the gnulib clone, and repeatedly rerun the commands:
$ ./gnulib-tool --create-testdir --dir=../testdir2 --single-configure MODULE1 [MODULE2...]
$ cd ../testdir2
$ ./configure CPPFLAGS=-Wall && make && make check

Bruno
Tim Rühsen
2017-05-16 13:52:15 UTC
Permalink
Bruno ! You saved my day !


I put your description with some small amendments into the README.
Here's the patch.


With Best Regards, Tim
Post by Bruno Haible
Hi Tim,
Post by Tim Rühsen
Not sure how to build and run the test suite. The README just points me
to a .texi file which is hardly readable, at least I get a headache
after ~10s.
I agree. The README should better say to
$ cd doc
$ make gnulib.html
$ xdg-open gnulib.html
or read the manual at
https://www.gnu.org/software/gnulib/manual/gnulib.html
Post by Tim Rühsen
What else should I try to build + run the test suite ?
You first pick a subset of the Gnulib modules, that you want to work on.
$ ./gnulib-tool --create-testdir --dir=../testdir1 --single-configure MODULE1 [MODULE2...]
This testdir is something you can "./configure CPPFLAGS=-Wall && make && make check".
- If you don't specify any, it defaults to *all*!
$ ./gnulib-tool --create-testdir --dir=../testdir-posix --single-configure `./posix-modules`
Note the difference between --dir=../testdir1 and --dir=/tmp/testdir1 : The former is on the
same file system as the gnulib checkout, and uses hard links to the .c and .h files; therefore
for quick edits of only .h and .c files you can do the edits in the testdir, test them
through "make" and "make check", and will usually find them present in the gnulib clone.
In the second case, or when you start to edit .m4 files or module descriptions, it's useful
$ ./gnulib-tool --create-testdir --dir=../testdir2 --single-configure MODULE1 [MODULE2...]
$ cd ../testdir2
$ ./configure CPPFLAGS=-Wall && make && make check
Bruno
Tim Rühsen
2017-05-16 14:55:15 UTC
Permalink
Oh, just realized that ChangeLog has to be manually edited.

Here is the amended patch.


With Best Regards, Tim
Post by Tim Rühsen
Bruno ! You saved my day !
I put your description with some small amendments into the README.
Here's the patch.
With Best Regards, Tim
Post by Bruno Haible
Hi Tim,
Post by Tim Rühsen
Not sure how to build and run the test suite. The README just points me
to a .texi file which is hardly readable, at least I get a headache
after ~10s.
I agree. The README should better say to
$ cd doc
$ make gnulib.html
$ xdg-open gnulib.html
or read the manual at
https://www.gnu.org/software/gnulib/manual/gnulib.html
Post by Tim Rühsen
What else should I try to build + run the test suite ?
You first pick a subset of the Gnulib modules, that you want to work on.
$ ./gnulib-tool --create-testdir --dir=../testdir1 --single-configure MODULE1 [MODULE2...]
This testdir is something you can "./configure CPPFLAGS=-Wall && make && make check".
- If you don't specify any, it defaults to *all*!
$ ./gnulib-tool --create-testdir --dir=../testdir-posix --single-configure `./posix-modules`
Note the difference between --dir=../testdir1 and --dir=/tmp/testdir1 : The former is on the
same file system as the gnulib checkout, and uses hard links to the .c and .h files; therefore
for quick edits of only .h and .c files you can do the edits in the testdir, test them
through "make" and "make check", and will usually find them present in the gnulib clone.
In the second case, or when you start to edit .m4 files or module descriptions, it's useful
$ ./gnulib-tool --create-testdir --dir=../testdir2 --single-configure MODULE1 [MODULE2...]
$ cd ../testdir2
$ ./configure CPPFLAGS=-Wall && make && make check
Bruno
Bruno Haible
2017-05-17 08:15:23 UTC
Permalink
Hi Tim,
Post by Tim Rühsen
I put your description with some small amendments into the README.
Here's the patch.
Thanks for being so pro-active.

-Please see doc/gnulib-readme.texi for basic information about Gnulib.
+Please create and read the docs with
+
+ $ cd doc
+ $ make gnulib.html
+ $ xdg-open gnulib.html
+
+or read the online manual at
+
+ https://www.gnu.org/software/gnulib/manual/gnulib.html

This is OK. Pushed.

+#### Contributor's Quick Start Guide ####

This does not belong in the README. The README is for first-time *users*.
For first-time *contributors*, many GNU packages have a HACKING file,
but gnulib already has a doc section "Contributing to gnulib".

+Note the difference between --dir=../testdir1 and --dir=/tmp/testdir1 : The former is on the
+same file system as the gnulib checkout, and uses hard links to the .c and .h files; therefore
+for quick edits of only .h and .c files you can do the edits in the testdir

This is not in a state where we could document it: Unfortunately it does not
work with the 'kate' editor (it breaks hard links when saving with backup).
I need to try how it works with symlinks instead.

Bruno
Tim Rühsen
2017-05-17 08:44:14 UTC
Permalink
Hi Bruno,
Post by Bruno Haible
Hi Tim,
+#### Contributor's Quick Start Guide ####
This does not belong in the README. The README is for first-time *users*.
For first-time *contributors*, many GNU packages have a HACKING file,
but gnulib already has a doc section "Contributing to gnulib".
I considered that, but thought that *users* are in fact *developers* and
thus potential *contributors*. Anyways, if you move that text into
HACKING (or sort of) it would let interested developers jump in quick
(that's why there is *Quick* in the title), first starting a browser to
search for the needed information might be too tedious for some people.
('Hackers' are known to be lazy when it comes to reading docs).
Post by Bruno Haible
+Note the difference between --dir=../testdir1 and --dir=/tmp/testdir1 : The former is on the
+same file system as the gnulib checkout, and uses hard links to the .c and .h files; therefore
+for quick edits of only .h and .c files you can do the edits in the testdir
This is not in a state where we could document it: Unfortunately it does not
work with the 'kate' editor (it breaks hard links when saving with backup).
I need to try how it works with symlinks instead.
Hard links are not portable and you hardly find software that does 'the
right thing', especially not editors that normally do backups and/or
saving into temp files + moving. Symlinks might be a problem as well.
Good luck.

With Best Regards, Tim
Bruno Haible
2017-05-20 11:24:58 UTC
Permalink
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 <***@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
Paul Eggert
2017-05-20 22:12:12 UTC
Permalink
Post by Bruno Haible
* 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.
It works for me with Emacs, possibly because I have had the following in my
~/.emacs for many years:

(setq backup-by-copying-when-linked t)
(setq backup-by-copying-when-mismatch t)

I prefer the hard links; for me, they work better than symlinks would, because
Emacs would chatter at me about following symlinks. I don't want to worry about
symlinks vs hardlinks when editing these files; I just want to change the file
everywhere without fuss. So I'd like to retain the ability to create test dirs
with hard links, at least as an option.

How about something like the attached patch? The idea is to use hard links by
default (the longstanding practice), and use symlinks if --symlink is given. If
you'd prefer to implement a new --hardlink option, I could live with that.
Bruno Haible
2017-05-21 10:44:43 UTC
Permalink
Hi Paul,
Post by Paul Eggert
How about something like the attached patch? The idea is to use hard links by
default (the longstanding practice)
No, something is not a good default if it requires editor customizations in
order to work correctly.

It is "longstanding practice", yes, but I did not perceive how badly it
operates, because I was always putting my testdirs in /tmp, thus avoiding
the hard links.

I can add options -h / --hardlink, -H / --more-hardlinks, with similar logic as
-s / --symlink, -S / --more-symlinks. But before doing that, I'd like to
understand whether it's worth the added complexity.

Namely, wouldn't symlinks work as well as hard links for you? vi, emacs, kate
have the same backup behaviour for symlinks: leave the symlink in place and
add the backup file in the directory of the target (i.e. in the gnulib
checkout). I find this a better starting point for new users if all editors do
things in the same way.
Post by Paul Eggert
I prefer the hard links; for me, they work better than symlinks would, because
Emacs would chatter at me about following symlinks.
You mean the question
Symbolic link to Git-controlled source file; follow link? (yes or no)
When you set vc-follow-symlinks to nil, it does not ask any more, it only shows
a warning
Warning: symbolic link to Git-controlled source file

Really I wonder about the point of these two warnings
Warning: symbolic link to Git-controlled source file
Warning: editing through the link bypasses version control
found in emacs/lisp/vc/vc-hooks.el.
If the target file is under version control, it gives the user the ability to
review and undo unintended changes afterwards. Whereas if the target file is
NOT under version control, changes can not be reviewed, and the edit history
is limited. Therefore it's the opposite situation which should warrant a
warning!
Warning: editing a file that is not under version control

Bruno
Paul Eggert
2017-05-21 19:37:02 UTC
Permalink
Post by Bruno Haible
I can add options -h / --hardlink, -H / --more-hardlinks, with similar logic as
-s / --symlink, -S / --more-symlinks.
I wasn't thinking of anything that complicated, though of course it would
suffice. I was just wanting the longstanding behavior.
Post by Bruno Haible
You mean the question
Symbolic link to Git-controlled source file; follow link? (yes or no)
Yes, that's the main annoyance I was thinking of.
Post by Bruno Haible
When you set vc-follow-symlinks to nil,
I don't want to do that. I want to edit just one file and have it affect
everything I'm working on, without hassling me about it. Better, I suppose,
would be setting vc-follow-symlinks to t, but that sounds too drastic for other
stuff that I'm working on, where the default value 'ask' is often the right
thing to do.
Bruno Haible
2017-05-21 19:54:32 UTC
Permalink
Hi Paul,
Post by Paul Eggert
Post by Bruno Haible
When you set vc-follow-symlinks to nil,
I don't want to do that. I want to edit just one file and have it affect
everything I'm working on
"gnulib-tool -S" and (setq vc-follow-symlinks nil) achieves just that, as far
as I can see from experiments.
Post by Paul Eggert
without hassling me about it.
You could get rid of the useless warning
"Warning: symbolic link to Git-controlled source file"
since you are close to the Emacs developers.
Post by Paul Eggert
Better, I suppose, would be setting vc-follow-symlinks to t,
When you set vc-follow-symlinks to t, then at the next file you open, it shows
you the directory of the gnulib checkout, not the testdir's contents. Which is
usually not what you want.
Post by Paul Eggert
for other
stuff that I'm working on, where the default value 'ask' is often the right
thing to do.
Well, in this case, if for other projects 'ask' is better, I'll implement
the options -h / --hardlink, -H / --more-hardlinks.

Bruno
Bruno Haible
2017-05-21 23:41:21 UTC
Permalink
Post by Bruno Haible
Post by Paul Eggert
for other
stuff that I'm working on, where the default value 'ask' is often the right
thing to do.
Well, in this case, if for other projects 'ask' is better, I'll implement
the options -h / --hardlink, -H / --more-hardlinks.
Implemented as follows:



2017-05-21 Bruno Haible <***@clisp.org>

gnulib-tool: Add options to create hard links.
* gnulib-tool (func_usage): Document options --hardlink,
--local-hardlink, --more-hardlinks.
(func_symlink): Renamed from func_ln.
(func_symlink_if_changed): Renamed from func_ln_if_changed.
(func_hardlink): New function.
(copymode, lcopymode): New variables.
(symbolic, lsymbolic): Remove variables.
(Options): Implement options --hardlink, --local-hardlink,
--more-hardlinks.
(func_should_link): Renamed from func_should_symlink. Set copyaction.
(func_add_file, func_update_file): Update invocation of
func_should_link. Invoke func_hardlink when appropriate.
(func_import): Update comments.
(func_create_testdir): Update invocation of func_should_link. Invoke
func_hardlink when appropriate.
Finally, invoke 'git update-index --refresh' to mitigate the effects of
the hard links on git.

diff --git a/gnulib-tool b/gnulib-tool
index c5b993a..a0dc037 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -295,11 +295,16 @@ Options for --import, --add/remove-import, --update,
-s, --symbolic, --symlink Make symbolic links instead of copying files.
--local-symlink Make symbolic links instead of copying files, only
for files from the local override directory.
+ -h, --hardlink Make hard links instead of copying files.
+ --local-hardlink Make hard links instead of copying files, only
+ for files from the local override directory.

Options for --import, --add/remove-import, --update:

-S, --more-symlinks Make symbolic links instead of copying files, and
don't replace copyright notices.
+ -H, --more-hardlinks Make hard links instead of copying files, and
+ don't replace copyright notices.

Report bugs to <bug-***@gnu.org>."
}
@@ -788,10 +793,10 @@ func_ln_s ()
}
}

-# func_ln SRC DEST
+# func_symlink SRC DEST
# Like func_ln_s, except that SRC is given relative to the current directory (or
# absolute), not given relative to the directory of DEST.
-func_ln ()
+func_symlink ()
{
case "$1" in
/* | ?:*)
@@ -811,22 +816,34 @@ func_ln ()
esac
}

-# func_ln_if_changed SRC DEST
-# Like func_ln, but avoids munging timestamps if the link is correct.
-func_ln_if_changed ()
+# func_symlink_if_changed SRC DEST
+# Like func_symlink, but avoids munging timestamps if the link is correct.
+# SRC is given relative to the current directory (or absolute).
+func_symlink_if_changed ()
{
if test $# -ne 2; then
- echo "usage: func_ln_if_changed SRC DEST" >&2
+ echo "usage: func_symlink_if_changed SRC DEST" >&2
fi
ln_target=`func_readlink "$2"`
if test -h "$2" && test "$1" = "$ln_target"; then
:
else
rm -f "$2"
- func_ln "$1" "$2"
+ func_symlink "$1" "$2"
fi
}

+# func_hardlink SRC DEST
+# Like ln, except use cp -p if ln fails.
+# SRC is given relative to the current directory (or absolute).
+func_hardlink ()
+{
+ ln "$1" "$2" || {
+ echo "$progname: ln failed; falling back on cp -p" >&2
+ cp -p "$1" "$2"
+ }
+}
+
# Ensure an 'echo' command that
# 1. does not interpret backslashes and
# 2. does not print an error message "broken pipe" when writing into a pipe
@@ -1052,10 +1069,14 @@ func_determine_path_separator
# given, blank otherwise
# - autoconf_minversion minimum supported autoconf version
# - doit : if actions shall be executed, false if only to be printed
-# - symbolic true if --symlink or --more-symlinks was given, blank
-# otherwise
-# - lsymbolic true if --local-symlink was given, blank otherwise
-# - do_copyrights blank if --more-symlinks was given, true otherwise
+# - copymode symlink if --symlink or --more-symlinks was given,
+# hardlink if --hardlink or --more-hardlinks was given,
+# blank otherwise
+# - lcopymode symlink if --local-symlink was given,
+# hardlink if --local-hardlink was given,
+# blank otherwise
+# - do_copyrights blank if --more-symlinks or --more-hardlinks was given,
+# true otherwise
{
mode=
destdir=
@@ -1093,8 +1114,8 @@ func_determine_path_separator
witness_c_macro=
vc_files=
doit=:
- symbolic=
- lsymbolic=
+ copymode=
+ lcopymode=
do_copyrights=true

supplied_opts="$@"
@@ -1371,16 +1392,26 @@ func_determine_path_separator
doit=false
shift ;;
-s | --symbolic | --symboli | --symbol | --symbo | --symb | --symlink | --symlin | --symli | --syml | --sym | --sy )
- symbolic=true
+ copymode=symlink
shift ;;
--local-symlink | --local-symlin | --local-symli | --local-syml | --local-sym | --local-sy | --local-s )
- lsymbolic=true
+ lcopymode=symlink
shift ;;
- -S | --more-symlinks | --more-symlink | --more-symlin | --more-symli | --more-syml | --more-sym | --more-sy | --more-s | --more- | --more | --mor | --mo )
- symbolic=true
+ -h | --hardlink | --hardlin | --hardli | --hardl | --hard | --har | --ha )
+ copymode=hardlink
+ shift ;;
+ --local-hardlink | --local-hardlin | --local-hardli | --local-hardl | --local-hard | --local-har | --local-ha | --local-h )
+ lcopymode=hardlink
+ shift ;;
+ -S | --more-symlinks | --more-symlink | --more-symlin | --more-symli | --more-syml | --more-sym | --more-sy | --more-s )
+ copymode=symlink
+ do_copyrights=
+ shift ;;
+ -H | --more-hardlinks | --more-hardlink | --more-hardlin | --more-hardli | --more-hardl | --more-hard | --more-har | --more-ha | --more-h )
+ copymode=hardlink
do_copyrights=
shift ;;
- --help | --hel | --he | --h )
+ --help | --hel | --he )
func_usage
func_exit $? ;;
--version | --versio | --versi | --vers )
@@ -3302,19 +3333,26 @@ func_is_local_file ()
func_path_foreach "$local_gnulib_path" test %dir% = "$dname"
}

-# func_should_symlink
-# returns 0 when the file $f should be symlinked
+# func_should_link
+# determines whether the file $f should be copied, symlinked, or hardlinked.
# Input:
-# - symbolic true if files should be symlinked, copied otherwise
-# - lsymbolic true if files from local_gnulib_path should be symlinked,
-# copied otherwise
+# - copymode copy mode for files in general
+# - lcopymode copy mode for files from local_gnulib_path
# - f the original file name
# - lookedup_file name of the merged (combined) file
-func_should_symlink ()
+# Sets variable:
+# - copyaction copy or symlink or hardlink
+func_should_link ()
{
- test -n "$symbolic" \
- || { test -n "$lsymbolic" \
- && func_is_local_file "$lookedup_file" "$f"; }
+ if test -n "$lcopymode" && func_is_local_file "$lookedup_file" "$f"; then
+ copyaction="$lcopymode"
+ else
+ if test -n "$copymode"; then
+ copyaction="$copymode"
+ else
+ copyaction=copy
+ fi
+ fi
}

# func_add_file
@@ -3330,19 +3368,25 @@ func_should_symlink ()
# - g the rewritten file name
# - tmpfile absolute filename of the temporary file
# - doit : if actions shall be executed, false if only to be printed
-# - symbolic true if files should be symlinked, copied otherwise
-# - lsymbolic true if files from local_gnulib_path should be symlinked,
-# copied otherwise
+# - copymode copy mode for files in general
+# - lcopymode copy mode for files from local_gnulib_path
func_add_file ()
{
if $doit; then
echo "Copying file $g"
- if func_should_symlink \
+ func_should_link
+ if test "$copyaction" = symlink \
&& test -z "$lookedup_tmp" \
&& cmp -s "$lookedup_file" "$tmpfile"; then
- func_ln_if_changed "$lookedup_file" "$destdir/$g"
+ func_symlink_if_changed "$lookedup_file" "$destdir/$g"
else
- mv -f "$tmpfile" "$destdir/${g}" || func_fatal_error "failed"
+ if test "$copyaction" = hardlink \
+ && test -z "$lookedup_tmp" \
+ && cmp -s "$lookedup_file" "$tmpfile"; then
+ func_hardlink "$lookedup_file" "$destdir/$g"
+ else
+ mv -f "$tmpfile" "$destdir/${g}" || func_fatal_error "failed"
+ fi
fi
else
echo "Copy file $g"
@@ -3362,9 +3406,8 @@ func_add_file ()
# - g the rewritten file name
# - tmpfile absolute filename of the temporary file
# - doit : if actions shall be executed, false if only to be printed
-# - symbolic true if files should be symlinked, copied otherwise
-# - lsymbolic true if files from local_gnulib_path should be symlinked,
-# copied otherwise
+# - copymode copy mode for files in general
+# - lcopymode copy mode for files from local_gnulib_path
# - already_present nonempty if the file should already exist, empty otherwise
func_update_file ()
{
@@ -3379,12 +3422,19 @@ func_update_file ()
echo "Replacing file $g (non-gnulib code backed up in ${g}~) !!"
fi
mv -f "$destdir/$g" "$destdir/${g}~" || func_fatal_error "failed"
- if func_should_symlink \
+ func_should_link
+ if test "$copyaction" = symlink \
&& test -z "$lookedup_tmp" \
&& cmp -s "$lookedup_file" "$tmpfile"; then
- func_ln_if_changed "$lookedup_file" "$destdir/$g"
+ func_symlink_if_changed "$lookedup_file" "$destdir/$g"
else
- mv -f "$tmpfile" "$destdir/${g}" || func_fatal_error "failed"
+ if test "$copyaction" = hardlink \
+ && test -z "$lookedup_tmp" \
+ && cmp -s "$lookedup_file" "$tmpfile"; then
+ func_hardlink "$lookedup_file" "$destdir/$g"
+ else
+ mv -f "$tmpfile" "$destdir/${g}" || func_fatal_error "failed"
+ fi
fi
else
if test -n "$already_present"; then
@@ -4408,9 +4458,8 @@ func_reconstruct_cached_local_gnulib_path ()
# given, blank otherwise
# - autoconf_minversion minimum supported autoconf version
# - doit : if actions shall be executed, false if only to be printed
-# - symbolic true if files should be symlinked, copied otherwise
-# - lsymbolic true if files from local_gnulib_path should be symlinked,
-# copied otherwise
+# - copymode copy mode for files in general
+# - lcopymode copy mode for files from local_gnulib_path
# - do_copyrights true if copyright notices in files should be replaced,
# blank otherwise
func_import ()
@@ -4964,7 +5013,7 @@ s,^\(.................................................[^ ]*\) *,
exec 0<&5 5<&-
}

- # Copy files or make symbolic links. Remove obsolete files.
+ # Copy files or make symbolic links or hard links. Remove obsolete files.
added_files=''
removed_files=''
delimiter=' '
@@ -5887,9 +5936,8 @@ s,//*$,/,'
# --no-conditional-dependencies was given, blank otherwise
# - libtool true if --libtool was given, false if --no-libtool was
# given, blank otherwise
-# - symbolic true if files should be symlinked, copied otherwise
-# - lsymbolic true if files from local_gnulib_path should be symlinked,
-# copied otherwise
+# - copymode copy mode for files in general
+# - lcopymode copy mode for files from local_gnulib_path
func_create_testdir ()
{
testdir="$1"
@@ -6067,7 +6115,7 @@ func_create_testdir ()
exec 0<&5 5<&-
}

- # Copy files or make symbolic links.
+ # Copy files or make symbolic links or hard links.
delimiter=' '
for f in $files; do echo $f; done \
| sed -e "s,^.*\$,&$delimiter&," -e "$sed_rewrite_files" \
@@ -6084,10 +6132,15 @@ func_create_testdir ()
if test -n "$lookedup_tmp"; then
cp -p "$lookedup_file" "$testdir/$g"
else
- if func_should_symlink; then
- func_ln "$lookedup_file" "$testdir/$g"
+ func_should_link
+ if test "$copyaction" = symlink; then
+ func_symlink "$lookedup_file" "$testdir/$g"
else
- cp -p "$lookedup_file" "$testdir/$g"
+ if test "$copyaction" = hardlink; then
+ func_hardlink "$lookedup_file" "$testdir/$g"
+ else
+ cp -p "$lookedup_file" "$testdir/$g"
+ fi
fi
fi
done
@@ -7057,6 +7110,17 @@ s/\([.*$]\)/[\1]/g'
func_fatal_error "unknown operation mode --$mode" ;;
esac

+if test "$copymode" = hardlink -o "$lcopymode" = hardlink; then
+ # Setting hard links modifies the ctime of files in the gnulib checkout.
+ # This disturbs the result of the next "gitk" invocation.
+ # Workaround: Let git scan the files. This can be done through
+ # "git update-index --refresh" or "git status" or "git diff".
+ if test -d "$gnulib_dir"/.git \
+ && (git --version) >/dev/null 2>/dev/null; then
+ (cd "$gnulib_dir" && git update-index --refresh >/dev/null)
+ fi
+fi
+
rm -rf "$tmp"
# Undo the effect of the previous 'trap' command. Some shellology:
# We cannot use "trap - 0 1 2 3 13 15", because Solaris sh would attempt to
Paul Eggert
2017-05-22 02:37:13 UTC
Permalink
Thanks, that was fast! I'll give it a try soon (though perhaps not as quickly as
you did...).

Loading...