Patch to fix working of autogen.sh

Patch to fix working of autogen.sh

[Neil Jerram]

I propose to commit the patch below, to allow autogen.sh to work
again.  This is for 1.8.x and HEAD.

The snapshot builder at
ftp://ftp.dt.e-technik.uni-dortmund.de/pub/guile/snapshots/ uses
autogen.sh, so hopefully this patch will also cause the 1.8.x and HEAD
snapshots to start appearing again.

(Doing AM_GNU_GETTEXT_VERSION causes autopoint to be run, which causes
the creation of a po subdir, with various boilerplate files, but I see
no harm in that.)

Any comments before I commit this?

Regards,
     Neil


Index: ChangeLog
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/ChangeLog,v
retrieving revision 1.488
diff -u -r1.488 ChangeLog
--- ChangeLog	28 Jan 2007 09:36:51 -0000	1.488
+++ ChangeLog	28 Jan 2007 09:39:14 -0000
@@ -1,5 +1,11 @@
 2007-01-28  Neil Jerram  <neil@ossau.uklinux.net>
 
+	* configure.in: Do AM_GNU_GETTEXT_VERSION, so that autoreconf will
+	run autopoint.
+
+	* acinclude.m4 (AM_INTL_SUBDIR): Provide dummy definition, to work
+	around current autoconf/automake/gettext bug.
+
 	* INSTALL: New upstream version.
 
 	* ABOUT-NLS: New upstream version.
Index: acinclude.m4
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/acinclude.m4,v
retrieving revision 1.18
diff -u -r1.18 acinclude.m4
--- acinclude.m4	6 Jun 2006 21:39:42 -0000	1.18
+++ acinclude.m4	28 Jan 2007 09:39:14 -0000
@@ -308,3 +308,5 @@
 fi
 AC_LANG_RESTORE
 ])dnl ACX_PTHREAD
+
+AC_DEFUN([AM_INTL_SUBDIR], [])dnl
Index: configure.in
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/configure.in,v
retrieving revision 1.280
diff -u -r1.280 configure.in
--- configure.in	15 Jan 2007 23:07:49 -0000	1.280
+++ configure.in	28 Jan 2007 09:39:15 -0000
@@ -706,6 +706,7 @@
 #fi
 #AC_CHECK_FUNCS([bindtextdomain textdomain])
 AM_GNU_GETTEXT([external], [need-ngettext])
+AM_GNU_GETTEXT_VERSION([0.16])
 
 ### Some systems don't declare some functions.  On such systems, we
 ### need to at least provide our own K&R-style declarations.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Patch to fix working of autogen.sh

[Neil Jerram]

Neil Jerram <neil@ossau.uklinux.net> writes:

> I propose to commit the patch below, to allow autogen.sh to work
> again.  This is for 1.8.x and HEAD.

Actually I went ahead with committing this for HEAD, to see if we get
a snapshot tonight (European time).

> Any comments [...]

would still be welcome.

Regards,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Patch to fix working of autogen.sh

[Kevin Ryde]

Neil Jerram <neil@ossau.uklinux.net> writes:
>
> (Doing AM_GNU_GETTEXT_VERSION causes autopoint to be run, which causes
> the creation of a po subdir, with various boilerplate files, but I see
> no harm in that.)

An actual release doesn't have a po subdir yet does it?  Can you make
the autogen give what should go out the door?  It might mean running
the desired aclocal/autoconf/automake combination explicitly, instead
of trusting autoreconf -- I'm guessing autoreconf is wrongly (for us)
deciding it needs to gettextize.

> +
> +AC_DEFUN([AM_INTL_SUBDIR], [])dnl

Put an enormous comment there if you would, otherwise it's bound to
make everyone wonder what it's for.

(Oh, and no need for the dnl on the end, autoconf prunes newlines out
ok.)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Patch to fix working of autogen.sh

[Neil Jerram]

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

> Neil Jerram <neil@ossau.uklinux.net> writes:
>>
>> (Doing AM_GNU_GETTEXT_VERSION causes autopoint to be run, which causes
>> the creation of a po subdir, with various boilerplate files, but I see
>> no harm in that.)
>
> An actual release doesn't have a po subdir yet does it?

Not sure, haven't tried a make dist yet.  I suspect that it would do,
and agree with you that it shouldn't!

> Can you make the autogen give what should go out the door?

That's the intention.

>  It might mean running the desired aclocal/autoconf/automake
> combination explicitly, instead of trusting autoreconf -- I'm
> guessing autoreconf is wrongly (for us) deciding it needs to
> gettextize.

OK, here's the full trail as I understand it.  My preference would be
to stick with autoreconf, as I assume the autoreconf guys have thought
more carefully about all the edge cases in this magic than we have.

We start off with two problems.

(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.

(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 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.

In fact, we don't need the real AM_INTL_SUBDIR, so (1) can be fixed by
adding an empty definition for AM_INTL_SUBDIR.

For (2):

- config.rpath is apparently required for linking to the gettext
  library (which Guile genuinely needs, I believe), and it is
  installed, if not already present by autopoint

- 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 ...

- ... but unfortunately, then autopoint also generates the po
  directory and boilerplate files.

So now, I believe there are two options.

1. Leave as is, and live with the po directory - probably even in the
   dist.

2. Remove AM_GNU_GETTEXT_VERSION, so autopoint doesn't run, and
   instead add config.rpath to CVS and EXTRA_DIST.

We could make (1) more palatable by actually starting to
internationalize Guile's internal strings - so then we would really
need the po directory!

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.)

>> +
>> +AC_DEFUN([AM_INTL_SUBDIR], [])dnl
>
> Put an enormous comment there if you would, otherwise it's bound to
> make everyone wonder what it's for.

Will do.  Let's just agree the whole solution first though.

> (Oh, and no need for the dnl on the end, autoconf prunes newlines out
> ok.)

Thanks, I'll remove it.

Regards,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Patch to fix working of autogen.sh

[Kevin Ryde]

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.

> (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.

> 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?

> - config.rpath is apparently required for linking to the gettext
>   library (which Guile genuinely needs, I believe),

Yep.

> - 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 ...

> 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?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Patch to fix working of autogen.sh

[Neil Jerram]

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