Paul Eggert wrote:
> > 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.
No, it's not a "better way" to ask the user to add one more directory to his
PATH.
1) Users should not need to extend their PATH for a single program.
Because then, the PATH becomes more complicated and thus more
prone to producing unexpected effects. (Similar to the CLASSPATH
in Java. About 50% of issues in the Java world are CLASSPATH
issues. Because for each installed package, CLASSPATH needs to
be extended by 1 entry, typically.)
Traditionally, every element of $PATH is for a _category_ of programs:
The system maintenance tools, the applications, the games, the
programs installed by the sysadmin, the programs installed by the
user.
2) It would cause constraints to ourselves: We could not have
MODULES.html.sh, all-modules, check-copyright, etc. as programs
at the top-level of gnulib. These programs are supposedly private
to gnulib.
> 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.
But gnulib-tool is meant to be used from anywhere. Many packages use
the older approach of committing gnulib-cache.m4 under version control,
and the update command in this situation is just "gnulib-tool --update".
> If people are actually using gnulib-tool via this symlink trick then we
> should keep supporting it.
The documentation has been describing this approach for 15 years.
Therefore it is guaranteed that a number of people use this symlink trick.
> But I'm truly curious as to who they are and
> why they want to do that rather than the obvious thing.
My $HOME/bin/ directory has more than 20 symlinks, from 'shellcheck' to
'nyxt'. To me, that's the "obvious" thing, not adding 20 more directories
to PATH.
Bruno
