[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


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.

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
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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]