Re: The drawbacks of the --symlink option

[Paul Eggert]

Bruno Haible <address@hidden> writes:

>   @code{gnulib-tool} can make symbolic links instead of copying the
> ! source files.  The option to specify for this is @samp{--symlink}, or
> ! @samp{-s} for short.  This can be useful to save a few kilobytes of disk
> ! space.

-s isn't for saving disk space.  If that were the issue, we wouldn't
bother.  -s is for not having two slightly-different copies of the
same file, which is a real maintenance hassle for people who commonly
change both gnulib and the application.

The symlinks aren't perfect, but for someone like me they are more
reliable than gnulib-tool --update, since I often wouldn't remember to
invoke gnulib-tool, and even if I remembered I probably wouldn't
remember the options I'd have to give it (which are currently packaged
inside 'bootstrap'), and even if I remembered the options gnulib-tool
--update would take an appreciable time to run.

It's OK to put in a warning about the problems with symlinks, but the
proposed wording is a bit too negative I think.