gnulib-tool.py: --symbolic and --hardlink support

[Dmitry Selyutin]

Hello everyone!


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? I mean, are these options used in practice? If
not, dropping them could simplify the code a little bit as well as the future
maintenance. The potential speed-up that gnulib-tool.py could have gained with
these options seems to be marginal.

If these options do have a large use, I will surely implement them, though I
must really think a lot how to integrate them in a better way. I'd be very
grateful for your feedback.

[Paul Eggert]

I see a big amount of code > regarding --symlink and --hardlink; do these options have use except

of > speeding up the gnulib-tool? I mean, are these options used in
practice?
I use --hardlink so that when I edit files with Emacs I update both the
gnulib-tool-generated file and the original source file, without
worrying about how I got to the file. I imagine others use --symlink for
the same reason, though I don't use it much.

[Bruno Haible]

Hi Dmitry,

Post by Dmitry Selyutin
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].

Post by Dmitry Selyutin
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

[Dmitry Selyutin]

Hi Bruno, Paul,

thank you for tips! Now I think I've come up with the decision how to handle
both options (and this decision basically resembles the original handling).
I've updated both configuration and parser logic on the python branch, and now
I move forward to the file processing. Thank you!