Re: bison and i18n

[Bruno Haible]

Tim Van Holder wrote:
> Wouldn't it make more sense to use a bison-runtime domain instead of an
> application-bison one?  It might need to be versioned (e.g.
> bison-runtime-2.0), but having a copy for each app that uses bison seems
> excessive.

You are right in observing that here the best choice is not obvious. I can
see three ways of distributing bison's .mo files in such a way that
applications built with different versions of bison can coexist and be
100% localized:

  1) Have a bison-runtime package that contains the .mo files, unversioned.

  2) Have a versioned bison-runtime package, containing the .mo files for
     a particular bison version each.
     a) This package is installed by "make install" of bison.
     b) This package is installed by "make install" of each package that
        uses a parser.

  3) Have a package-dependent bison-runtime package, shipped with and
     installed by each package that uses a parser.

Each of these solution has drawbacks:

  1) - The bison-runtime.pot file can only ever grow over time. A special
       po/Makefile.in.in rule must ensure that old messages are always kept
       even if the current yacc.c doesn't refer to them any more.
     - The distributors / binary package creators must learn to add a
       dependency to bison-runtime to many packages.

  2) - Takes more room on disk than 1).
     - The distributors / binary package creators must learn to add a
       dependency to bison-runtime-<VERSION> to many packages, where the
       version depends on the package and furthermore can change at every
       release.

  2b) also
      - The "make install" / "make uninstall" rules must be written in such
        a way that the same installed files can be shared by multiple
        packages. The experience with 'charset.alias' shows that many
        distributors / binary package creators have a problem with that,
        because the general assumption is that no two packages are responsible
        for installing the same file.

  3) - Takes more room on disk than 1) or 2).

The patch I submitted uses approach 3. But I admit that approach 1 is also
tempting. The drawback that a file is only ever growing already exists in
other places (e.g. the glibc ABIs, or gettext's archive.tar.gz) and is not
dramatic. The drawback regarding the bison-runtime dependency would be void
if there is agreement to introduce a bison-runtime package _anyway_.

Bruno