[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
distributions.
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
problem.
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,
Stepan