Kevin Ryde <[EMAIL PROTECTED]> writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>>
>> (1) autoreconf exits with error status, because it thinks that the
>> expansion of AM_GNU_GETTEXT requires a definition of
>> AM_INTL_SUBDIR, and AM_INTL_SUBDIR isn't defined.
>
> If it thinks that then I guess it's not recognising "external" in
> AM_GNU_GETTEXT.
Yes. I can find discussion dating from 2002/3 saying that this was a
bug in automake. Surprising if it still hasn't been fixed since then.
I uninstalled my 1.7 /usr/bin/automake, to make sure I wasn't picking
up old stuff from 1.7 by mistake. Then my automake must be the 1.10
in /usr/local/bin, but I still see messages indicating that it isn't
recognising the "external":
autoreconf: configure.in: not using Gettext
...
autoreconf: configure.in: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION
These aren't fatal though.
>> (2) If you get past (1), one of the subsequent build steps (forget
>> which one) fails because there is no config.rpath in the top level
>> directory.
>
> I don't remember how I got that into my working dir. I expect it was
> from running gettextize then reverting the excessive changes that
> program makes.
That sounds to me like a vote for solution (2): adding config.rpath to
CVS and to EXTRA_DIST.
>> I understand that (1) is caused by an inconsistency between aclocal
>> and autoconf. When aclocal decides what macros we need in aclocal.m4,
>> it correctly decides that we don't need AM_INTL_SUBDIR. When autoconf
>> checks that we have all the macros that we need, it incorrectly thinks
>> we do need AM_INTL_SUBDIR.
>
> Yep. Sounds very fishy. Is this the latest and greatest gettext
> macros?
I believe so:
[EMAIL PROTECTED]:~$ gettext --version
gettext (GNU gettext-runtime) 0.16
Copyright (C) 1995-1997, 2000-2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Ulrich Drepper.
Some Google hits suggest that this was traced to a bug in m4, which
has now been fixed - but I have the latest and greatest m4 too:
[EMAIL PROTECTED]:~$ m4 --version
GNU M4 1.4.8
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Rene' Seindal.
>> - config.rpath is apparently required for linking to the gettext
>> library (which Guile genuinely needs, I believe),
>
> Yep.
Thanks for confirming that.
>
>> - autopoint only runs, however, if configure.in contains both
>> AM_GNU_GETTEXT and AM_GNU_GETTEXT_VERSION
>>
>> - therefore I solved (2) by adding AM_GNU_GETTEXT_VERSION ...
>
> Not that there's anything stopping us running it explicitly of course,
> if we know it's needed ...
True. It seems now we're better off not running autopoint, though.
>> We could make (1) more palatable by actually starting to
>> internationalize Guile's internal strings - so then we would really
>> need the po directory!
>
> Depends I guess if anyone wants to work on that. Could do an en_AU
> translation, by adding "bloody" and "strewth" at various places :-)
>
> <unnamed port>:1:1: Wrong bloody type (expecting pair): x
:-)
>> On the other hand, (2) has the benefit that it should allow the
>> nightly snapshot to build. (I now know from the build machine's log
>> that the snapshot is failing because autopoint is not installed on the
>> build machine.)
>
> That doesn't mean it's an old (old-ish) gettext does it?
Yes, I think it does mean that.
Well, I've updated CVS now to try solution (2). It works locally for
me; let's see whether it works for the nightly snapshot too.
Regards,
Neil
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
