[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: Thu, 2 Jun 2005 21:29:50 +0200
User-agent: Mutt/1.4.1i

Hello Arnold,

>       fprintf(stderr, dgettext("bison-rt", "parse stack blown!\n"));
> 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).

no, this is what would confuse the packaging mechanism of various

I think that Bruno's solution, when each project brings it's own copy
of *.mo files is better.  We just have to make sure that as soon as the
rule *.y --> *.c is triggered, the *.mo files are refreshed.

If you install message catalogues, you don't care about every KB.
And if you do, you can link all these catalogues to one of the copies.

> In short, there are existing, MUCH simpler, MUCH easier mechanisms
> in place that can solve this problem.  Adding Yet Another Shared
> Library is a BIG MISTAKE.

I agree that inventing a new shared library is not a solution to this

But there is another question:
Yacc was invented before shared libraries were common, right?
Shouldn't we stop and ask ourselves: isn't the yacc skeleton big enough,
so that it would deserve to be moved to a separate library?
The generated *.c files would contain the tables and the code fragments,
but the skeleton code would live in a separate library.

If we decide that this is worth it, that we can pack the catalogue with
the shared library.

If we decide that moving the bison skeleton code to a separate library
is wrong idea, then I believe Bruno's solution is the best one.

Have a nice day,

reply via email to

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