unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* 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).