From: Neil Jerram <neil@ossau.uklinux.net>
To: Guile Development <guile-devel@gnu.org>
Subject: Re: Patch to fix working of autogen.sh
Date: Tue, 06 Feb 2007 23:19:52 +0000 [thread overview]
Message-ID: <87ejp2oovb.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <87odoh8kd9.fsf@zip.com.au> (Kevin Ryde's message of "Tue, 30 Jan 2007 10:48:50 +1100")
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
next prev parent reply other threads:[~2007-02-06 23:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-28 9:44 Patch to fix working of autogen.sh Neil Jerram
2007-01-28 16:00 ` Neil Jerram
2007-01-29 23:48 ` Kevin Ryde
2007-02-06 23:19 ` Neil Jerram [this message]
2007-02-07 23:23 ` Kevin Ryde
2007-02-18 23:21 ` Neil Jerram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ejp2oovb.fsf@ossau.uklinux.net \
--to=neil@ossau.uklinux.net \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).