Re: bison and i18n

[Stepan Kasal]

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