New PATCH for CVS mainline sources to make ``--enable-nls'' work

Jeffrey A Law
Sun Feb 28 18:15:00 GMT 1999

  In message < >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

  >  > 
  >  > Here are some comments about your patches to gcc/po/
  >  > 
  >  >    +#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.


More information about the Gcc-patches mailing list