GCC 3.0 Release Criteria

[Philipp Thomas]

* Mark Mitchell (mark@codesourcery.com) [20000430 03:23]:

> I doubt it.  In particular, I doubt that we'll be any more
> internationalized than we are now, barring major contributions.

Well, most of the machinery, which was the work of Paul Eggert,
is already in place.

>     Philipp> And while we're on that point, I'd also like to restate
>     Philipp> my whish to default to --enable-nls in CVS.
> 
> This sounds like a good first step to me.  It will force us to start
> dealing with the kinds of options you mentioned above.  
> I would welcome a patch to make this the default,

Patch and Changelog are attached :) Of cause this requires that
gcc/configure gets regenerated.

> so long as it includes all the right autoconf magic so that if NLS is not
> supported on the host system (because libraries are not present), that it
> is not then activated.

Well, it's even better than that :) gcc/intl contains the source for libintl
(from gettext), which will be compiled if either the host libs don't supply
gettext(), dcgettext() etc, or the user specified --with-included-gettext.
Prerequisites are locale() support and the gettext utilities. If one of them
is missing, NLS support will be disabled.

As I stated, most of the needed machinery is allready there and has been
there for quite some time, as Paul did his work for gcc 2.8 initially and
then adapted it for egcs.

> And you have to find a way to deal with cross compilers as well, I guess. 
> Hmm.

Oops. I hadn't thought about that and the current gettext machinery sure as
hell won't cope with that. I've never dealt with cross compiler issues
before, so I'd need info from those having experience here. What
combinations of build and target hosts are possible? And what are steps
taken when building a cross compiler.

>From the (very) limited view of the issues I have, at least these would be
necessary:

 - If build != target, the gettext configury would have to check for
   availability of the needed features in the target libs. AFAIK, presence
   of the necessary target libs is already a prerequisite, no?

 - If gettext support is missing on the target system, libintl would have to
   be built.

I'd say we should, for the moment, disable NLS support for cross compilation
and concentrate on getting it right for the build == target case. This would
include thinking about ways to split catalogs so that combinations of base
system + additional language does work. I'd possibly even go as far as
disabling it if not building from complete source, if for nothing else than
to get a starting point. Just scanning the complete source tree to check
that all places, where messages are output, are covered by the i18n support
will take quite a bit of time.

Having at least the support for the IMHO most common case turned on would
also be an encouragement for folks in the FSF translation teams to start
translating the gcc message catalog(s) as they would know that future users
of gcc would benefit from their work.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h