bug-gnu-utils
[Top][All Lists]
Advanced

[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




reply via email to

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