[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: |
Tue, 31 May 2005 21:03:33 +0200 |
User-agent: |
Mutt/1.4.1i |
Hello,
On Mon, May 30, 2005 at 08:39:51AM +0200, 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.
well, the bison-generated *.c file is distributed. That implies that
you use many versions of bison on your computer, each tarball brings
its own version. So you wouldn't save that much.
And the bison-runtime-2.0 scheme would confuse packaging systems of
distributions.
> It's unfortunate that bison doesn't have any user-side installation at
> the moment; it's much easier for the dcgettext model to be used for
> libraries, as the .mo files can just be installed along with the .a/.so.
You might be right. The parser could be a shared lib, and when
you'd call bison --libison, you'd get a *.c file which would define
a big data structure, all the code from *.y file glued together with
a very small amount of code.
The configure script could then look for installed bison + libison,
and if it would find it, it would throw away the distributed *.c file
and regenerate it with bison --libison .
Nice dream. Do you have capacities to give it a try?
Have a nice day,
Stepan
- Re: bison and i18n,
Stepan Kasal <=