[Comerrers] Welcome and proposal

[Theodore Ts'o]

On Tue, Apr 30, 2002 at 11:07:49PM -0400, Derrick J Brashear wrote:
> It's been a week since I sent the invitation to this list, so I figure
> everyone who's going to join, has.
> 
> I offer this proposal in the vein of internationalization:
> -a flag to compile_et which will cause it to generate .po files

I assume you mean the lex/sed version of compile_et?

Aside from the perl version of compile_et which Alexis mentioned,
there is also a pure awk version which is used by e2fsprogs and the
MIT krb5 tree.  I wrote the awk replacement compile_et when I got
tired of dealing with (a) incompatibilities between the various
versions of yacc/byacc/bison floating out in the world, and I think
some incompatibilities in lex/flex as well, and (b) because it was a
real pain as far as cross-compiling was concerned.

There is a compile_et shell script driver program for the awk/sed
version, but some of the makefiles also use Makefile rules which call
the awk script directly:

.et.h:
	$(AWK) -f $(SRCTOP)/util/et/et_h.awk outfile=$*.h $<

.et.c:
	$(AWK) -f $(SRCTOP)/util/et/et_c.awk outfile=$*.c $<

> -another flag to compile_et (or perhaps the default and a flag to disable)
>  which causes error_message, com_err et al to call gettext on the message 
>  string. If this defaults to on, it should only do so if the system
>  supports gettext, either natively or as a result of the comerr
>  implementation including a suitable library (which GNU gettext may or may
>  not be due to licensing considerations for any given environment, but
>  that's out of scope)

I think it's a really bad idea for there to be different versions of
the generated *et.c and *et.h files, depending on what flags are given
to compile_et, or the result of an autoconf run.  The compatibility
problems this can cause may be a major headache, since we need to deal
with all sorts of different permutations:

	* The calling program may be using gettext --- or may not.
	* The shared library containing the error tables may be
		compiled on a machine where the gettext library is
		present --- or may not
	* Once compiled, the the shared library be moved to another
		system where the gettext library may be available ---
		or may not.

The way I'd handle this is let there be an initialization function
which must be called by the program which initializes the base et
library.  One of the things which this function can pass in is a
pointer to the gettext function, or NULL if program isn't supporting
GNU gettext.  (This initialization function may also be architecture
dependent, if Windows or MacOS has specific needs that can't be
handled in this generic fashion).

This way, the et library doesn't have any dependencies on the libintl,
and is fully backwards compatible with older programs.  It also solves
the problem you mentioned:

> Neither of these is terribly complicated, the most problematic is "do all
> known implementations of gettext work correctly when e.g.
>   setlocale();
>   bindtextdomain();
>   textdomain();
> haven't happened."

						- Ted