bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]