This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: New PATCH for CVS mainline sources to make ``--enable-nls'' work
- To: manfred at s-direktnet dot de, mh at exept dot de
- Subject: Re: New PATCH for CVS mainline sources to make ``--enable-nls'' work
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Tue, 23 Feb 1999 11:04:15 -0700
- cc: eggert at twinsun dot com, bothner at cygnus dot com, egcs-patches at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <14033.27381.709956.483357@exept.exept.de>you write:
> > Those files are generated automatically, so they don't need to be
> > checked in. However, some maintainers like to check in the files
> > anyway. Hmm, what's the tradition at Cygnus for internationalized
> > software?
>
> If everybody has the necessary programs installed, OK. I'm afraid
> though, they don't; I'd prefer to check them into the tree.
> Jeff, opinions?
I'd like to avoid checking in yet more generated files into the source
tree. I'm not familiar enough with the i18n to know whether or not it
makes more sense to have the files in the source tree or to generate them
for the release/snapshot tarballs, but not include the files in the source
tree.
> >
> > Here are some comments about your patches to gcc/po/POTFILES.in:
> >
> > +#getopt.c is part of libiberty in egcs
> >
> > Unfortunately, this change will break the localization of several
> > strings in getopt.c, e.g. "%s: option `%s' is ambiguous\n". How do
> > other programs that use libiberty address this issue? One hacky
> > workaround is to plant a symbolic link from getopt.c to
> > ../libiberty/getopt.c, just so that xgettext can see it. But I hope
> > there's a better way.
>
> OK, so let's use the relative pathname to where the files in
> question are actually living? I just tried it and nothing broke.
We've going away from the ../.. symlink stuff. The right way to fix this
is to add all the i18n hooks to libiberty too. And move the intl subdir
so that it's a sibling of libiberty, gcc, gas, etc.
I'm not going to look at the patch yet -- I'm looking at the mainline solaris
bootstrap problem, then returning to concentrating on egcs-1.1.2. This stuff
can wait until we push egcs-1.1.2 out the door.
jeff