* doc gettext
@ 2005-01-09 22:48 Kevin Ryde
2005-01-10 21:11 ` Bruno Haible
[not found] ` <200501202239.07346.bruno@clisp.org>
0 siblings, 2 replies; 11+ messages in thread
From: Kevin Ryde @ 2005-01-09 22:48 UTC (permalink / raw)
Cc: Bruno Haible
I'm looking at the text below to expand what's in the guile reference
manual for gettext. It adds some examples and some bits of advice.
I'm a bit unsure about bind-textdomain-codeset. Thinking about it, if
Guile gets its own notion of coding systems or whatever in the future
then I'm wondering if that function might become obsolete, or even
actively harmful. It does some good now, but maybe some strong
warning against possible future change is needed.
5.20 Support for Internationalization
=====================================
Guile provides an interface to GNU `gettext' for translating message
strings (*note Introduction: (gettext)Introduction.).
Message domains allow messages from different programs or libraries
to be kept separate. A domain is just a string (it becomes part of the
message catalog filename).
When `gettext' is not available, or if Guile was configured
`--without-nls', dummy functions doing no translation are provided.
-- Scheme Procedure: gettext msg [domain [category]]
-- C Function: scm_gettext (msg, domain, category)
Return the translation of MSG in DOMAIN. DOMAIN is optional and
defaults to the domain set through `textdomain' below. CATEGORY
is optional and defaults to `LC_MESSAGES'.
If a program has many messages, a shorthand can be created. `_'
is usual for this, and is recognised by `xgettext' (*note Invoking
the `xgettext' Program: (gettext)xgettext Invocation.).
(define _ gettext)
(display (_ "You are in a maze of twisty passages."))
In a library the same can be done, but usually a domain should be
given explicitly, so it will still work if an application makes
itself as the default.
(define (_ msg) (gettext msg "mylibrary"))
(display (_ "File not found."))
Such a shorthand is also a good place to perhaps strip
disambiguating extra text from the message string, as per for
instance *Note How to use `gettext' in GUI programs: (gettext)GUI
program problems.
-- Scheme Procedure: ngettext msg msg_plural n [domain [category]]
-- C Function: scm_ngettext (msg, msg_plural, n, domain, category)
Return the translation of MSG/MSG_PLURAL in DOMAIN, with the
plural form chosen appropriately for the number N. DOMAIN is
optional and defaults to the domain set through `textdomain'
below. CATEGORY is optional and defaults to `LC_MESSAGES'. For
example,
(define (done n)
(format #t (ngettext "~a file processed\n"
"~a files processed\n" n)
n))
It's important to use `ngettext' for plurals, to allow translators
to give the proper forms for various N in other languages.
-- Scheme Procedure: textdomain [domain]
-- C Function: scm_textdomain (domain)
Get or set the default gettext domain. When called with DOMAIN,
it is set as the default, and that new value returned. When called
with no parameter the current domain is returned. For example,
(textdomain "myprog")
=> "myprog"
-- Scheme Procedure: bindtextdomain domain [directory]
-- C Function: scm_bindtextdomain (domain, directory)
Get or set the directory under which to find message files for
DOMAIN. When called with a DIRECTORY, DIRECTORY is set for DOMAIN
and that new setting returned. When called without a DIRECTORY
the current setting is returned. For example,
(bindtextdomain "myprog" "/my/tree/share/locale")
=> "/my/tree/share/locale"
When using Autoconf/Automake, an application should arrange for the
configured `localedir' to get into the program (by substituting,
or generating a config file) and set that for its domain. This
ensures the catalog can be found even when installed in a
non-standard location.
-- Scheme Procedure: bind-textdomain-codeset domain [encoding]
-- C Function: scm_bind_textdomain_codeset (domain, encoding)
Get or set the text encoding to be used by `gettext' for messages
from DOMAIN. ENCODING is a string, the name of a coding system,
for instance "8859_1". (On a GNU system the `iconv' program can
list all available encodings.)
When called with an ENCODING, it is set for DOMAIN and that new
setting returned. When called without an ENCODING the current
setting is returned, or `#f' if none yet set. For example,
(bind-textdomain-codeset "myprog")
=> #f
(bind-textdomain-codeset "myprog" "latin-9")
=> "latin-9"
The encoding requested can be different from the translated data,
messages will be recoded as necessary. But note that when there
is no translation `gettext' returns its MSG unchanged, ie.
without any recoding. For that reason source message strings are
best as plain ASCII.
Currently Guile has no understanding of multi-byte characters, and
string functions won't recognise character boundaries in multi-byte
strings. An application will at least be able to pass such strings
through to some output though. Perhaps this will change in the
future.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: doc gettext
2005-01-09 22:48 doc gettext Kevin Ryde
@ 2005-01-10 21:11 ` Bruno Haible
2005-01-23 23:20 ` Kevin Ryde
[not found] ` <200501202239.07346.bruno@clisp.org>
1 sibling, 1 reply; 11+ messages in thread
From: Bruno Haible @ 2005-01-10 21:11 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]
Kevin Ryde wrote:
> I'm looking at the text below to expand what's in the guile reference
> manual for gettext.
You can also use text from my original proposal (attached). It has the merit
of explaining the terms (domain, category, ...) that are used in the refman.
Also it contains complete workable examples. (You need to change the set!
notation to the optional-argument notation that is used in guile, though.)
> I'm a bit unsure about bind-textdomain-codeset. Thinking about it, if
> Guile gets its own notion of coding systems or whatever in the future
> then I'm wondering if that function might become obsolete, or even
> actively harmful.
When that happens, the bind-textdomain-codeset function should become a
nop.
> It does some good now, but maybe some strong
> warning against possible future change is needed.
But since in the present this function is _necessary_, I don't think it's
useful to make people doubt whether they should use it or not.
When bind-textdomain-codeset is no longer needed, you can easily make
the compiler emit a warning when it's used.
Bruno
[-- Attachment #2: guile-gettext.html --]
[-- Type: text/html, Size: 17344 bytes --]
[-- Attachment #3: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* building guile from CVS
[not found] ` <87d5vzd6bb.fsf@zip.com.au>
@ 2005-01-21 12:09 ` Bruno Haible
2005-01-21 14:06 ` Marius Vollmer
0 siblings, 1 reply; 11+ messages in thread
From: Bruno Haible @ 2005-01-21 12:09 UTC (permalink / raw)
Hi,
Configuring guile-core from CVS so that it builds requires a wizard.
Although I can claim to be an old autoconf and automake user, I needed
two hours and the help from Kevin Ryde to get it running.
Therefore I'd suggest that you add some instructions to guile-core/autogen.sh
so that it does become so extremely frustrating to attempt to build guile.
# =====================================================================
# The above commands can fail under some circumstances.
# Here are instructions for getting things working manually.
#
# 1) You need autoconf 2.59, automake 1.9.x in the $PATH.
# You also need libtool >= 1.5 installed, say, under $LIBTOOL_PREFIX.
# You also need gettext >= 0.11.2 installed, say, under $GETTEXT_PREFIX.
#
# 2) Use these commands to update guile-core:
# $LIBTOOL_PREFIX/bin/libtoolize --force --copy --ltdl
# cp $LIBTOOL_PREFIX/share/aclocal/libtool.m4 guile-config/libtool.m4
# aclocal -I guile-config
# autoconf
# autoheader && touch config.h.in
# automake -a
# cp $GETTEXT_PREFIX/share/gettext/config.rpath config.rpath
#
# 3) Use these commands to update guile-core/guile-readline:
# (cd guile-readline
# aclocal -I ../guile-config
# autoconf
# automake -a
# )
#
# 4) For the first configure, use
# ./configure --enable-maintainer-mode
Bruno
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building guile from CVS
2005-01-21 12:09 ` building guile from CVS Bruno Haible
@ 2005-01-21 14:06 ` Marius Vollmer
2005-01-21 15:41 ` Bruno Haible
0 siblings, 1 reply; 11+ messages in thread
From: Marius Vollmer @ 2005-01-21 14:06 UTC (permalink / raw)
Cc: guile-devel
Bruno Haible <bruno@clisp.org> writes:
> Configuring guile-core from CVS so that it builds requires a wizard.
> Although I can claim to be an old autoconf and automake user, I needed
> two hours and the help from Kevin Ryde to get it running.
I can feel your pain. :-]
Yes, getting Guile to compile from a fresh CVS checkout is not as easy
as it can be. But I wouldn't put all the blame on Guile. Guile
doesn't do anything out of the ordinary, as far as I am aware (now
that we have dropped our own version libltdl), but the autotools still
have trouble with it. For example, when no installed libltdl is
found, Guile builds its own in the way that libtool prescribes it, but
then libtool can't find the freshly build libltdl when we run the
freshly build guile executable during the build.[1]
There _is_ a big bug in Guile tho (courtesy myself): when checking out
guile-core, there is no documentation on how to proceed. These docs
are in the file HACKING, but that file is hidden deeply in the
guile/workbook module. Not good. I have added a README.CVS file to
CVS. Also HACKING didn't talk about the guile-scripts and workbook
modules that you need as well in order to build guile-core. I fixed
that as well.
If that was the source of your frustration, please accept my sincere
apologies.
> Therefore I'd suggest that you add some instructions to guile-core/autogen.sh
> so that it does become so extremely frustrating to attempt to build guile.
Why do you want to add instructions to autogen.sh that contradict what
autogen.sh is doing itself? Shouldn't we fix autogen.sh, preferably?
> # 2) Use these commands to update guile-core:
> # $LIBTOOL_PREFIX/bin/libtoolize --force --copy --ltdl
> # cp $LIBTOOL_PREFIX/share/aclocal/libtool.m4 guile-config/libtool.m4
I don't want to make Guile more complicated by catering to what could
be called 'broken' installations of libtool, etc. If libtoolize is
not in the path and libtool.m4 is not found by aclocal, then the
installation of libtool is 'broken'. You might bitch that it is too
complicated to install libtool correctly, and you are probably right,
but hey, I at least don't care. ;-)
> # aclocal -I guile-config
There are no files in guile-config that are needed by aclocal (except
those that you have copied there in step 2.)
> # autoconf
> # autoheader && touch config.h.in
> # automake -a
Isn't autoreconf supposed to do this? If it doesn't, it's a bug in
autoreconf, right?
So, when there are bugs in how we use the autotools, we should of
course fix them. If there are simple workarounds for bugs in the
latest released versions of the autotools, we should use them as well.
But adding instructions to autogen.sh to do manually what autogen.sh
is supposed to do automatically is not going to help much, I'm afraid.
[1] Hmm, maybe this has something to do with cross-compilation magic
that we don't do properly...
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building guile from CVS
2005-01-21 14:06 ` Marius Vollmer
@ 2005-01-21 15:41 ` Bruno Haible
2005-01-21 21:45 ` Kevin Ryde
2005-02-28 1:17 ` Marius Vollmer
0 siblings, 2 replies; 11+ messages in thread
From: Bruno Haible @ 2005-01-21 15:41 UTC (permalink / raw)
Cc: guile-devel
Marius Vollmer wrote:
> > # autoconf
> > # autoheader && touch config.h.in
> > # automake -a
>
> Isn't autoreconf supposed to do this? If it doesn't, it's a bug in
> autoreconf, right?
Right. But when autoreconf failed, it left me clueless about what was
wrong.
> I have added a README.CVS file to CVS.
Thanks, that is a good place to put the instructions.
> > # 2) Use these commands to update guile-core:
> > # $LIBTOOL_PREFIX/bin/libtoolize --force --copy --ltdl
> > # cp $LIBTOOL_PREFIX/share/aclocal/libtool.m4 guile-config/libtool.m4
>
> I don't want to make Guile more complicated by catering to what could
> be called 'broken' installations of libtool, etc.
Then there are no working libtool releases that work for guile:
- libtool 1.4.x create no libltdl/ directory,
- libtool 1.5.x breaks 'aclocal', see http://sources.redhat.com/ml/automake/2003-04/msg00222.html
- libtool 1.6.x are not released on ftp.gnu.org.
> You might bitch that it is too
> complicated to install libtool correctly, and you are probably right,
> but hey, I at least don't care. ;-)
If the README.CVS would tell which version of libtool is required, it would
be fine.
> Why do you want to add instructions to autogen.sh that contradict what
> autogen.sh is doing itself? Shouldn't we fix autogen.sh, preferably?
OK. Then here's what I see when I use the instructions. (I have
autoconf 2.59, automake 1.9.4, gettextize 0.14.1 and libtoolize 1.4.3
in the PATH.) It is enough to leave a wizard clueless.
$ ./autogen.sh
You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
ls: libltdl/*: No such file or directory
configure.in:57: warning: AC_CANONICAL_HOST invoked multiple times
/packages/gnu/autoconf-2.59/tests/../lib/autoconf/specific.m4:393: AC_MINGW32 is expanded from...
configure.in:57: the top level
configure.in:57: warning: AC_CANONICAL_HOST invoked multiple times
/packages/gnu/autoconf-2.59/tests/../lib/autoconf/specific.m4:393: AC_MINGW32 is expanded from...
configure.in:57: the top level
autoreconf: `configure.ac' or `configure.in' is required
I already debugged this, so here's the broken-down list of problems in
guile:
1) It calls libtoolize without prior check that the libtoolize version is
>= 1.5. libtoolize 1.4.3 does not create an ltdl/ directory, therefore
it is unusable. (I would also add checks for minimum versions of
autoconf and automake, btw.)
2) It doesn't copy libtool.m4 into guile-config/, but it should.
libtoolize doesn't do it. 'aclocal' will not find the libtool.m4 file
if libtool and automake have been installed with different --prefix
parameters.
3) It would help to call "autoreconf --verbose". Then at least the output
is more informative:
$ autoreconf --verbose
autoreconf: Entering directory `.'
autoreconf: configure.in: not using Gettext
autoreconf: running: aclocal -I guile-config
configure.in:57: warning: AC_CANONICAL_HOST invoked multiple times
/home/haible/gnu/autoconf-2.59/tests/../lib/autoconf/specific.m4:393: AC_MINGW32 is expanded from...
configure.in:57: the top level
autoreconf: configure.in: tracing
configure.in:57: warning: AC_CANONICAL_HOST invoked multiple times
/home/haible/gnu/autoconf-2.59/tests/../lib/autoconf/specific.m4:393: AC_MINGW32 is expanded from...
configure.in:57: the top level
autoreconf: configure.in: subdirectory libltdl to autoreconf
autoreconf: Entering directory `libltdl'
autoreconf: `configure.ac' or `configure.in' is required
4) The gettext .m4 macros are not present in guile-config/ and not
added by autoreconf. 'aclocal' will not find the gettext.m4 and related
files if gettext and automake have been installed with different --prefix
parameters.
5) Since AM_GNU_GETTEXT is used in configure.in, a config.rpath is needed.
autoreconf does not add it. 'autopoint' would add it, but is not invoked
from autoreconf.
6) "make" fails in the doc directory because version.texi doesn't exist.
Kevin Rude says that it should be fixed by
"configure --enable-maintainer-mode". But it would be better if autogen.sh
would solve this.
Bruno
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building guile from CVS
2005-01-21 15:41 ` Bruno Haible
@ 2005-01-21 21:45 ` Kevin Ryde
2005-01-22 14:03 ` Marius Vollmer
2005-01-24 15:25 ` Bruno Haible
2005-02-28 1:17 ` Marius Vollmer
1 sibling, 2 replies; 11+ messages in thread
From: Kevin Ryde @ 2005-01-21 21:45 UTC (permalink / raw)
Cc: guile-devel, Marius Vollmer
Bruno Haible <bruno@clisp.org> writes:
>
> - libtool 1.6.x are not released on ftp.gnu.org.
Umm, I think I got us both confused there. There isn't any 1.6.x, I
got that mixed up. I was thinking of 1.5.6.
> 5) Since AM_GNU_GETTEXT is used in configure.in, a config.rpath is needed.
> autoreconf does not add it. 'autopoint' would add it, but is not invoked
> from autoreconf.
Ah, yep. A gettextize is definitely now needed in autogen.sh.
autoreconf won't run that.
> 6) "make" fails in the doc directory because version.texi doesn't exist.
> Kevin Rude says that it should be fixed by
> "configure --enable-maintainer-mode". But it would be better if autogen.sh
> would solve this.
I'm not sure autogen.sh should get involved in that. Maybe README.CVS
should say to build the cvs with --enable-maintainer-mode, either
always or the first time at least.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building guile from CVS
2005-01-21 21:45 ` Kevin Ryde
@ 2005-01-22 14:03 ` Marius Vollmer
2005-01-24 15:25 ` Bruno Haible
1 sibling, 0 replies; 11+ messages in thread
From: Marius Vollmer @ 2005-01-22 14:03 UTC (permalink / raw)
Cc: guile-devel
Kevin Ryde <user42@zip.com.au> writes:
> Ah, yep. A gettextize is definitely now needed in autogen.sh.
> autoreconf won't run that.
Hmm, we had problems in the past with running gettextize in the
guile-core tree. We only wrap functions like gettext, we do not have
a translation structure in place for Guile itself.
Not-running gettextize is a bug-fix in autoreconf actually. Because
of that fix, we need autoconf 2.59 or later.
Maybe we have to run gettextize after all, but we explicitely do _not_
run it right now. See HACKING.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: doc gettext
2005-01-10 21:11 ` Bruno Haible
@ 2005-01-23 23:20 ` Kevin Ryde
0 siblings, 0 replies; 11+ messages in thread
From: Kevin Ryde @ 2005-01-23 23:20 UTC (permalink / raw)
Cc: guile-devel
> You can also use text from my original proposal (attached). It has the merit
> of explaining the terms (domain, category, ...) that are used in the refman.
I'd probably prefer to cross-reference the gettext manual for most
such things. There's a cross reference to the gettext
"Introduction", which hopefully covers most of the basics.
[bind-textdomain-codeset]
>
> But since in the present this function is _necessary_, I don't think it's
> useful to make people doubt whether they should use it or not.
Yep, I left it alone.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building guile from CVS
2005-01-21 21:45 ` Kevin Ryde
2005-01-22 14:03 ` Marius Vollmer
@ 2005-01-24 15:25 ` Bruno Haible
1 sibling, 0 replies; 11+ messages in thread
From: Bruno Haible @ 2005-01-24 15:25 UTC (permalink / raw)
Cc: guile-devel, Marius Vollmer
Kevin Ryde wrote:
> > 5) Since AM_GNU_GETTEXT is used in configure.in, a config.rpath is
> > needed. autoreconf does not add it. 'autopoint' would add it, but is not
> > invoked from autoreconf.
>
> Ah, yep. A gettextize is definitely now needed in autogen.sh.
No no no. gettextize is not suitable for running from within autogen.sh;
this is explained in the GNU gettext manual. You need autopoint instead.
> autoreconf won't run that.
Actually, autoreconf will do this if you add a AM_GNU_GETTEXT_VERSION
declaration in configure.in. But before doing that, run gettextize
once and _just_once_; then you put the AM_GNU_GETTEXT_VERSION line into
configure.in, with a version number that matches the one of gettextize
that you ran.
> > 6) "make" fails in the doc directory because version.texi doesn't exist.
> > Kevin Rude says that it should be fixed by
> > "configure --enable-maintainer-mode". But it would be better if
> > autogen.sh would solve this.
>
> I'm not sure autogen.sh should get involved in that.
autogen.sh is preferrable here because the creation of a version.texi is a
once-only thing. It's not needed in further runs. And not everyone using
a CVS snapshot is a maintainer.
Bruno
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building guile from CVS
2005-01-21 15:41 ` Bruno Haible
2005-01-21 21:45 ` Kevin Ryde
@ 2005-02-28 1:17 ` Marius Vollmer
2005-02-28 1:31 ` Marius Vollmer
1 sibling, 1 reply; 11+ messages in thread
From: Marius Vollmer @ 2005-02-28 1:17 UTC (permalink / raw)
Cc: guile-devel
Bruno Haible <bruno@clisp.org> writes:
> Then there are no working libtool releases that work for guile:
> - libtool 1.4.x create no libltdl/ directory,
> - libtool 1.5.x breaks 'aclocal', see http://sources.redhat.com/ml/automake/2003-04/msg00222.html
I think this bug does not affect Guile. Does it?
> OK. Then here's what I see when I use the instructions. (I have
> autoconf 2.59, automake 1.9.4, gettextize 0.14.1 and libtoolize
> 1.4.3 in the PATH.)
Does libtool 1.5.x work? We do not support libtool 1.4 any longer.
> It is enough to leave a wizard clueless.
Yeah. The autotools have grown into a problem of their own. Maybe
there should be a wrapper around them that simplifies their use...
Not! ;-)
Thank you very much for the list below!
> 1) It calls libtoolize without prior check that the libtoolize version is
> >= 1.5. libtoolize 1.4.3 does not create an ltdl/ directory, therefore
> it is unusable. (I would also add checks for minimum versions of
> autoconf and automake, btw.)
How would these checks look like? They would have to be very robust
and simple.
> 2) It doesn't copy libtool.m4 into guile-config/, but it should.
Why? How? Guile should not try to work around this installation bug,
I think. When aclocal from $PATH can not find the libtool.m4 that
goes with the libtool from $PATH, then how can Guile do it?
> 3) It would help to call "autoreconf --verbose".
Yes, that is helpful. I made this change.
> 4) The gettext .m4 macros are not present in guile-config/ and not
> added by autoreconf.
See 2)
>
> 5) Since AM_GNU_GETTEXT is used in configure.in, a config.rpath is needed.
> autoreconf does not add it. 'autopoint' would add it, but is not invoked
> from autoreconf.
So we need to invoke autopoint? after autoreconf or before? I have
added a call to autopoint after autoreconf.
(On the other hand, I don't have a config.rpath in my Guile tree and I
don't seem to need it.)
> 6) "make" fails in the doc directory because version.texi doesn't exist.
> Kevin Rude says that it should be fixed by
> "configure --enable-maintainer-mode". But it would be better if autogen.sh
> would solve this.
Yes. Do you have a solution?
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building guile from CVS
2005-02-28 1:17 ` Marius Vollmer
@ 2005-02-28 1:31 ` Marius Vollmer
0 siblings, 0 replies; 11+ messages in thread
From: Marius Vollmer @ 2005-02-28 1:31 UTC (permalink / raw)
Cc: guile-devel
Marius Vollmer <mvo@zagadka.de> writes:
> I have added a call to autopoint after autoreconf.
I didn't do this, after all. Using autopoint seems to require a
AM_GNU_GETTEXT_VERSION statement or something in configure.in and I
don't know which version to specify. I will accept patches, tho...
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-02-28 1:31 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-01-09 22:48 doc gettext Kevin Ryde
2005-01-10 21:11 ` Bruno Haible
2005-01-23 23:20 ` Kevin Ryde
[not found] ` <200501202239.07346.bruno@clisp.org>
[not found] ` <87d5vzd6bb.fsf@zip.com.au>
2005-01-21 12:09 ` building guile from CVS Bruno Haible
2005-01-21 14:06 ` Marius Vollmer
2005-01-21 15:41 ` Bruno Haible
2005-01-21 21:45 ` Kevin Ryde
2005-01-22 14:03 ` Marius Vollmer
2005-01-24 15:25 ` Bruno Haible
2005-02-28 1:17 ` Marius Vollmer
2005-02-28 1:31 ` Marius Vollmer
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).