Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson asked on 2007-12-03:
>> 1) Is it guaranteed that replacing the gettext M4 files with those in
>> gnulib will work with the gettext version installed?
>>
>> 2) Is it guaranteed that replacing the gnulib M4 files with those in
>> gettext will work with other gnulib macros?
>>
>> In other words, is there a hidden dependency between which gnulib and
>> gettext version I am using?
>>
>> And of course the final question, what is the recommended way to handle
>> the code-overlap between gnulib and gettextize in a project?
>
> I've now added a bit of documentation that should answer these questions:
Hi Bruno. Thanks! However:
> + The solution is therefore:
> +
> + @enumerate
> + @item
> + When you run @code{gettextize}, always use the @code{gettextize} from the
> + newest GNU gettext release found on @url{http://ftp.gnu.org/gnu/gettext/},
> + and invoke @code{gnulib-tool} afterwards.
That doesn't work for me currently -- I don't assume developers have
gnulib installed. Instead I store the gnulib-tool --import'ed files in
git. This has worked fine for a long time. Do we want to officially
abandon this way of using gnulib?
The bootstrap script approach could work, but there are two critical
problems that prevent me from using it: there is no way to reproduce the
gnulib state for a particular old release tag. Or is there? I need
this to be able to produce a security release that only contains the
security related patch. The second is that when I tested it a long time
ago, I found it quite slow. It checked out gnulib etc. To make sure my
projects are in a sane state, I often re-bootstrap them from a clean
checkout. This is already slow today, and making it even slower would
be unfortunate.
I think a few other gnulib users in users.txt use gnulib the same way
that I do. However, I'm willing to adapt to something else.
Alternatively, I could document the work-around I use to solve the
gettext vs gnulib vs autoconf problem right now: store all gnulib
generated files in git, and before running autoreconf move the gnulib
copy of config.rpath out of the way, and after running autoreconf, move
it back again. This have worked for several projects for quite some
time, but I'm not confident it is safe.
/Simon
