Update of sr #111238 (group autoconf):
Status: None => Confirmed
_______________________________________________________
Follow-up Comment #4:
Bruno: No, I'm not going to close this as invalid. The specific remedy
requested may be incorrect, but:
1) If I understand the discussion at https://savannah.gnu.org/bugs/?67090 and
https://savannah.gnu.org/bugs/index.php?66968 correctly, a change in gettext
broke building certain older packages from source. On its face, that is a
legitimate bug. A request for restored backward compatibility should always
be taken seriously, *even if* it appears that part of the problem is user
error. Of course it may not be possible to *accomplish* restored backward
compatibility without causing other problems, but that's no reason to be
dismissive.
2) From autoconf's perspective, `autoreconf -i [-f]` *is supposed to be
sufficient* to prepare one to run ./configure, except for very unusual cases,
such as trying to build Autoconf itself from a VCS checkout without any
pre-installed copy of Autoconf available. To put it another way, the intended
purpose of autoreconf is to be a *complete* substitute for project-specific
autogen.sh scripts.
Thus, to the extent "don't use autoreconf" is correct advice for the problem
Funda Wang was experiencing, *that is a bug in autoreconf*, and I see no
reason not to treat this as a report of that bug.
autoreconf *does* know how to run autopoint, but perhaps it is not doing it
correctly. What it currently does is grep configure.ac for occurrences of
AM_GNU_GETTEXT_(REQUIRE_)?VERSION. If any are found, it runs autopoint, as
its very first operation (in particular, before aclocal).
In https://savannah.gnu.org/bugs/index.php?66968 the recommended sequence
seems instead to be to run aclocal with --install *first*, *then* run
autopoint, then run aclocal again *without* --install. The problem with that
is, per the commentary in bin/autoconf.in, if you run aclocal on a source tree
with no pre-existing po.m4, without having run autopoint first, aclocal will
fail because it can't find the gettext macros.
Complicating matters still further, there exist projects that "intentionally
don't call AM_GNU_GETTEXT_(REQUIRE_)VERSION because they have all of the
gettext infrastructure checked into version control and they want [autoreconf]
to _not_ run autopoint"; any change will need to not break such projects.
I'd appreciate it if you could suggest any approach to threading a path
through all these semi-contradictory requirements.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/support/?111238>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
