[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bison and i18n
From: |
Aharon Robbins |
Subject: |
Re: bison and i18n |
Date: |
Thu, 02 Jun 2005 23:22:27 +0300 |
In article <address@hidden> you write:
>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.
You need to use the bison .mo files that match the generated parser.
>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.
I don't know that I saw this or understand it, but I'm not going
to worry about it.
>I agree that inventing a new shared library is not a solution to this
>problem.
Exactly.
>But there is another question:
>Yacc was invented before shared libraries were common, right?
Yes.
>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?
No, it's not big enough. It should not be in its own library. RAM is
cheap these days, and how many instances of a compiler or interpreter
are there running at the same time these days that the overhead of a
shared library is worth it?
>The generated *.c files would contain the tables and the code fragments,
>but the skeleton code would live in a separate library.
How is that going to work? The code fragments are embedded in the
generated code. I don't think it's possible to do this. It makes
every code fragment into some kind of function or something. *You
don't want to start down this path.*
>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.
It's the wrong idea. Take my word for it. Bison ain't broke, don't
go fixing it.
Thanks,
Arnold