And the culprit is: texinfo

[Philipp Thomas]

I nailed down the cause of the failure for the NLS stuff on
systems where the gettext tools aren't installed, it's texinfo. Texinfo is
also i18ned and thus also uses the damned gettext autconf macros, although
in their original form, which is flawed to say the least. The thing both
versions have in common are the cache variables.

Now texinfo is configured *before* gcc, so the cache vars get their wrong
contents and gcc's configure won't recheck as the values are cached. My fast
fix is to make texinfo use the same version of AM_WITH_NLS as gcc. BTW,
would such a patch be accepted? The right fix is to really remove texinfo as
we allready agreed upon but nobody volunteered to do the non-sexy and
potential hairy work.

As it's now biting me, I finally volunteer to do that work (which doesn't
seem that unusual a way such work is done :).

But in order to do the work, I need a recap of how the make machinery should
look like after the removal, i.e. how should it react when it either finds
no or outdated texinfo tools. The only thing I remembered is, that releases
and possibly snapshots should contain preformatted info pages. Could you by
any chance fill in my voids?

The really right thing IMNSHO would be to completely rewrite the whole
gettext NLS macro mess.

First step would be to seperate between the macros used by gettext and those
installed in $prefix/share/aclocal for use by gettextize and thus for all
other packages. For gettext itself it's OK to ignore the fact that no tools
are available as these will get built anyway (allthough as written the tests
are wrong even for gettext, as they will prefer installed tools instead of
those that are going to be built).

The second step would be to seperate building and using libintl from
creating the catalogs in those macros intended for use in the rest of the
software world. There's no reason why a binary shouldn't have the NLS
support built in independent of whether catalogs are present or 
tools for creating them are available.

All in all yet another reason for why active maintenance of the gettext
package is badly needed. But that's more medium range stuff.

Philipp 

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX for PDP 11, /usr/include/sys/param.h