I think this bug should NOT be fixed.

The reason is that ideally, there should be one and only one tool responsible for installing config.rpath in the developer's package when needed. It's already bad enough that three(!) tools do this: gettextize, autopoint, and gnulib-tool. This creates interdependencies between GNU gettext and GNU gnulib, that fortunately are bearable because GNU gnulib changes are effective immediately - no releases.

If we were to add a fourth tool (autoreconf), we would also have interdependencies between GNU autoconf and GNU gettext. Since GNU autoconf tends to have releases quite infrequently, roughly once every 3 years on average, this would mean that some aspects of GNU gettext could be blocked for several years. (There are also already interdependencies between GNU automake and GNU gettext. We have been lucky that this affects only a warning and nothing is blocked.)

It is better if this bug does not get fixed - this affects few users - than that the development of GNU gettext be partially blocked for years.

The proper way to fix this would be for 'autoreconf' to invoke some program (or shell script) that GNU gettext has installed. So that GNU gettext may evolve even if there are no new GNU autoconf releases for N years. Much like bash does with the bash completions: bash does not include completion logic for a multitude of package, but rather it has a mechanism through which packages can install their completion logic.

On further investigation it's not that simple after all.  An autogen.sh script is written knowing exactly what is needed for a particular project, but autoreconf needs to detect when a project needs this versus when it needs the full autopoint treatment and when it doesn't need either, and that's complicated enough by itself that I think this needs to wait for the next release after all.  Still, knowing what to do is very helpful.

Bruno, re

> if new files (.m4 files or else) are needed as new dependencies of iconv.m4, this method will not know about it

M4 dependencies should be taken care of by aclocal, shouldn't they?  I do see that new non-M4 dependencies could be a problem.

Here is simple autogen.sh script which can be used to avoid this AM_ICONV autoreconf bug:

#!/bin/sh

# Install config.rpath which is needed for AM_ICONV macro
for dir in "$GETTEXT_DIR" /usr/share/gettext /usr/local/share/gettext; do
  if test -f "$dir/config.rpath"; then
    test -f config.rpath || echo "autogen.sh: installing './config.rpath'"
    cp -f "$dir/config.rpath" .
    break
  fi
done

autoreconf --install --force --verbose

comment #1:

> > https://lists.gnu.org/archive/html/bug-gettext/2011-10/msg00012.html
> > When a project wants to only use AM_ICONV and none of the other gettext autoconf macros
>
> If your package only wants to use iconv() but no support for localized messages, it should use the gnulib module 'iconv'. This module includes the config.rpath file.

Could you show to me (and also to other people) a configure.ac example how to to use it? Yes I just need to use only iconv() library and ICONV_CONST macro in C source code which is provided by autoconf macro AM_ICONV.

> autoreconf deals with gettext for convenience. It does not know about gnulib modules.
>
> > projects which needs to use AM_ICONV started providing their own "autogen.sh" script which copies required file config.rpath to current directory and then run autoreconf.
>
> This is not future-proof: if new files (.m4 files or else) are needed as new dependencies of iconv.m4, this method will not know about it.

I know. But all projects started doing it due to above unfixed bug in autoreconf/autopoint/gettext and it started to be de-facto start way how to workaround above bug. And I'm just following this way.

This is old bug which was reported at least 10 years ago, affects more projects and there was no response for it yet. So I'm filling this bug report again.

Here is one of the original reports:
https://lists.gnu.org/archive/html/bug-gettext/2011-10/msg00012.html

Problem is that if autoconf project wants to use AM_ICONV macro without any other gettext macro support, autoreconf does not install required file config.rpath, which leads to broken configure script.

Details with reproducer are in linked bug above.

As a temporary workaround to this issue, projects which needs to use AM_ICONV started providing their own "autogen.sh" script which copies required file config.rpath to current directory and then run autoreconf.