On 7/4/24 20:17, Bruno Haible wrote:
Paul Eggert wrote:
PS. There's a lot of machinery in those shell scripts for the minor
benefit of letting gnulib-tool be a symlink in your $PATH to the real
gnulib-tool. How about if we drop support for this?
This is not a "minor" benefit, but a major one.
1) It's documented:
<https://www.gnu.org/software/gnulib/manual/html_node/Invoking-gnulib_002dtool.html>
Sure, but the proposed patch changes the documentation to say how to get
the benefit in a better way.
2) If it was not present, the user would have to write a shell-script
wrapper;
No, there's no need to write a wrapper; see the proposed patch to the
documentation. The new way is better than the old one, because it's a
simpler shell command, it requires no change to the file system, and
it'll work even on systems that don't support symlinks.
3) The GNU Coding Standards
The part of the standard you quoted is intended to apply to GNU programs
installed and used in the usual way. gnulib-tool is not such a program.
It's not intended to be used anywhere other than the Gnulib source
directory, and this reflects Gnulib's unusual role as a source-only library.
If people are actually using gnulib-tool via this symlink trick then we
should keep supporting it. But I'm truly curious as to who they are and
why they want to do that rather than the obvious thing.
