[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnulib-tool.py: --symbolic and --hardlink support
From: |
Bruno Haible |
Subject: |
Re: gnulib-tool.py: --symbolic and --hardlink support |
Date: |
Wed, 18 Oct 2017 23:01:25 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-96-generic; KDE/5.18.0; x86_64; ; ) |
Hi Dmitry,
> After a small break for a week, I continue rewriting gnulib-tool in Python.
> Right now I'm on the track to implement functions related to adding and
> updating the files (possibly via patching). I see a big amount of code
> regarding --symlink and --hardlink; do these options have use except of
> speeding up the gnulib-tool?
Yes! Speeding up gnulib-tool is not the focus here. It's developer convenience.
The common use-case of --hardlink is when someone is developing a gnulib
module. He's working simultaneously in a testdir tree and in the gnulib
checkout.
[1]
The common use-case of --symbolic is probably when someone is working
in a program that uses gnulib and wants the changes to be propagated back to
gnulib without effort. (The original submitter [2] gave no example.)
The usual situation for --local-symlink is when a program uses gnulib with
--local-dir (such as GNU gettext). A developer does not want multiple copies
of the same file in the source tree in this case.
For a long time --hardlinks was even the default for testdirs, but this was
not adequate [3].
> I will surely implement them, though I
> must really think a lot how to integrate them in a better way
Basically think of it like this: Every file has a "copy action", which
determines how to create the copy. There are 3 possible values { copy,
hardlink, symlink }. Which copy action to perform, depends on the options
(--symlink, --local-symlink, --hardlink, --local-hardlink) and where the
file comes from (local or global gnulib).
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2017-05/msg00118.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2005-04/msg00048.html
[3] https://lists.gnu.org/archive/html/bug-gnulib/2017-05/msg00181.html