Colin Watson <[EMAIL PROTECTED]> writes:
> I find the advice in gnulib's documentation "Caveat: gettextize and
> autopoint users" rather difficult to follow in practice. I prefer to use
> autoreconf rather than having to track which tools and options I'm
> supposed to be using, but autoreconf invokes autopoint followed by the
> other tools without letting me interpose a call to gnulib-tool. Of
> course I could call autopoint and gnulib-tool myself and then call
> autoreconf with AUTOPOINT=/bin/true, but that's clumsy at best.
>
> Is it worth proposing something like the attached patch to the Autoconf
> maintainers? Should it be controlled by a command-line option to
> autoreconf? I prefer to run 'gnulib-tool --update' every time I
> regenerate my autotools files, but I have a feeling some people follow
> different practices.
>
> I understand I'd need to send this to bug-autoconf, but wanted to run it
> by this list first.
Please make it possible to disable this behavior, if it is added. I
assume GNULIB_TOOL=/bin/true autoreconf will be sufficient?
I sometimes re-run 'autoreconf' in my projects' directories with
modifications to gnulib files when testing them. If autoreconf started
to invoke gnulib-tool, that would break overwrite my local changes.
FYI, I'm using the following rule to invoke autoreconf and to work
around the complaint from autopoint:
mv lib/build-aux/config.rpath lib/build-aux/config.rpath-
test -f ./configure || autoreconf --install
mv lib/build-aux/config.rpath- lib/build-aux/config.rpath
Once autopoint has been run from autoreconf once with config.rpath moved
away, re-running autoreconf (even with --install and --force) works
fine. I guess autopoint isn't invoked more than once.
/Simon
