* 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
* 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
[parent not found: <200501202239.07346.bruno@clisp.org>]
[parent not found: <87d5vzd6bb.fsf@zip.com.au>]
* 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: 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).