[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bison and i18n
From: |
Bruno Haible |
Subject: |
Re: bison and i18n |
Date: |
Tue, 31 May 2005 22:07:24 +0200 |
User-agent: |
KMail/1.5 |
Tim Van Holder wrote:
> Wouldn't it make more sense to use a bison-runtime domain instead of an
> application-bison one? It might need to be versioned (e.g.
> bison-runtime-2.0), but having a copy for each app that uses bison seems
> excessive.
You are right in observing that here the best choice is not obvious. I can
see three ways of distributing bison's .mo files in such a way that
applications built with different versions of bison can coexist and be
100% localized:
1) Have a bison-runtime package that contains the .mo files, unversioned.
2) Have a versioned bison-runtime package, containing the .mo files for
a particular bison version each.
a) This package is installed by "make install" of bison.
b) This package is installed by "make install" of each package that
uses a parser.
3) Have a package-dependent bison-runtime package, shipped with and
installed by each package that uses a parser.
Each of these solution has drawbacks:
1) - The bison-runtime.pot file can only ever grow over time. A special
po/Makefile.in.in rule must ensure that old messages are always kept
even if the current yacc.c doesn't refer to them any more.
- The distributors / binary package creators must learn to add a
dependency to bison-runtime to many packages.
2) - Takes more room on disk than 1).
- The distributors / binary package creators must learn to add a
dependency to bison-runtime-<VERSION> to many packages, where the
version depends on the package and furthermore can change at every
release.
2b) also
- The "make install" / "make uninstall" rules must be written in such
a way that the same installed files can be shared by multiple
packages. The experience with 'charset.alias' shows that many
distributors / binary package creators have a problem with that,
because the general assumption is that no two packages are responsible
for installing the same file.
3) - Takes more room on disk than 1) or 2).
The patch I submitted uses approach 3. But I admit that approach 1 is also
tempting. The drawback that a file is only ever growing already exists in
other places (e.g. the glibc ABIs, or gettext's archive.tar.gz) and is not
dramatic. The drawback regarding the bison-runtime dependency would be void
if there is agreement to introduce a bison-runtime package _anyway_.
Bruno