[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Libgettextpo wrapper for Guile
From: |
Bruno Haible |
Subject: |
Re: Libgettextpo wrapper for Guile |
Date: |
Sun, 05 May 2019 20:45:40 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-145-generic; KDE/5.18.0; x86_64; ; ) |
Hi Miguel,
> an external project would be useful anyway as
> does not require a version update of neither Gettext nor Guile to start
> using it
A separate project also means an independent release cycle.
How are other Guile bindings organized?
- guile-cairo separate project https://www.nongnu.org/guile-cairo/
- guile-gnome separate project
https://www.gnu.org/software/guile-gnome/
- guile-git separate project https://gitlab.com/guile-git/guile-git
- libgccjit separate project
https://savannah.nongnu.org/projects/gccjit-guile/
- guile-gnutls at gnutls
https://www.gnutls.org/manual/gnutls-guile.html
- zeromq at zeromq
http://zeromq.org/bindings:guile-binding
- gmp part of guile
https://gmplib.org/manual/Language-Bindings.html
The majority seems to have chosen to be available as separate project.
> I think the choice should have more to do with Gettext's desire as a
> project to extend its code base in Guile in the future, as the Guile
> library could be the foundation for new tools, or to keep C as the main
> code base
There are no plans to use a different implementation language for
PO file manipulations. With the existing code base as a start, it
is not much harder to code new functionality in C than it would be
to code it in Python, guile, Java, or other languages.
Gettext needs a different implementation language in other areas -
such as extracting relevant information from HTML pages - and is
using POSIX sh for this purpose. It's a balance between language
features, portability, and ease of installation / minimization of
dependencies.
Bruno