[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bison and i18n
From: |
Stepan Kasal |
Subject: |
Re: bison and i18n |
Date: |
Fri, 3 Jun 2005 08:59:47 +0200 |
User-agent: |
Mutt/1.4.1i |
Hello,
On Fri, Jun 03, 2005 at 12:51:44AM +0300, Eli Zaretskii wrote:
> > no, this is what would confuse the packaging mechanism of various
> > distributions.
>
> Please explain why this problem would happen.
Aharon proposed:
> > > Then all that's needed is some new autoconf/automake machinery to
> > > include the .mo files from the bison used on the developer's machine
> > > in the distribution, and then to install them if they're not there
> > > on the installation machine (assuming that gettext is available).
Imagine two projects, foo and bar, bot using the same version of bison.
`foo' installs the bison-rt.mo files.
--> The packaging system remembers them.
`bar' sees the files are already installed, so it doesn't install them.
--> The packaging doesn't know about them.
Then if you removed `foo', `bar' would break.
A similar problem:
if the distributor builds binary packages for foo and bar independently,
then both would contain the bison-rt.mo files. If you try to install
both of them, you'd get an error that both try to install the same file.
Solution:
The packages would have to build a separate package `bison-rt' and other
packages, like `gawk', would ``require'' it.
(Or perhaps the bison-rt.mo files can be bundled with basic gettext-runtime
package.)
So the distrubutor has to take an extra effort to adapt the distribution
to the new scheme.
I think it's not worth it. The original Bruno's solution avoids these
problems, at a small cost.
> > isn't the yacc skeleton big enough,
> > so that it would deserve to be moved to a separate library?
>
> The answer to that questions is: NO, the Yacc skeleton isn't big
> enough to be in a separate library.
OK, I think this case is closed. Thank you and Aharon.
Have a nice day,
Stepan