Re: Patch to fix working of autogen.sh

[Neil Jerram <neil@ossau.uklinux.net>]

Kevin Ryde <user42@zip.com.au> writes:

> Neil Jerram <neil@ossau.uklinux.net> 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:

neil@laruns:~$ 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:

neil@laruns:~$ 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