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 22:08:49 +0300

In article <address@hidden> you write:
>Hello,
>
>On Tue, May 31, 2005 at 10:07:24PM +0200, Bruno Haible wrote:
>> The drawback regarding the bison-runtime dependency would be void
>> if there is agreement to introduce a bison-runtime package _anyway_.
>
>I think this is an important point.
>
>If the bison-runtime contains only the .mo file, then many distributors
>will forget to set the dependency.
>But if we change bison so that it installs a shared library which will
>eventually be used bu the applications, then the dependency will be
>discovered automatically.

This is one of the worst ideas I've ever seen.  It is an excellent
example of the tail wagging the dog.

Requiring a runtime library for every program that uses bison would be
a disaster.  For example, is gawk supposed to include the code for the
bison library with it?  Not to mention all the autoconf machinery that
would be needed.  And not to mention that every time you install a new
shared library, you'd better remember to run `ldconfig' or everything
that uses it breaks. (This bit me upgrading to gettext 0.14.4.) I know
that sysadmins the world over would hate me.  NO THANK YOU.

If bison goes this way, I will drop it for Berkeley yacc faster than
you can say "hot potato".

Let's take a step back here.  The only problem is bison's messages in
the generated parser.  This is exactly what the dgettext() routine is
intended to solve:

        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).

If you then want to add options to bison so that configure scripts
can figure out what's going on, that's fine.

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.

My opinion,

Arnold
-- 
Aharon (Arnold) Robbins --- Pioneer Consulting Ltd.     arnold AT skeeve DOT com
P.O. Box 354            Home Phone: +972  8 979-0381    Fax: +1 206 350 8765
Nof Ayalon              Cell Phone: +972 50  729-7545
D.N. Shimshon 99785     ISRAEL




reply via email to

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