Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal

>> Hi, I propose to use gettext for i18n.
>
>
> This would add a new build and run-time dependency that I think we
> have to be
> very careful about handling. I really wish this could be made
> optional rather
> than being a mandatory requirement.

That's not true. Gettext is designed so as not to have this build or
runtime dependency. If there's no gettext available, the build will just
fall back to a non-internationalized version.

> The biggest problem is that GNU gettext expects us to be using
> automake, which
> isn't going to be used. I think the best course of action is to just
> discard
> everything that gettextize does and write our own configure checks and
> Makefile. This should have the added bonus of allowing us to work
> against
> non-GNU gettext and with non-GNU makes.

That's not true. There's nothing in the code I've posted which requires
automake. It does require autoconf though. And we don't want to support
non-GNU gettext's, thery are not as featureful.

> * Makefile.in: With the exception of the i18n targets, these changes are
> entirely bogus. DEFS and the LOCALEDIR are most certainly not options
> that
> should be passed to the compiler, but rather to the preprocessor.

Well... the compiler is the one calling the preprocessor, isn't it?

> The makefile should not have targets for configure, config.status,
> etc. (I have a
> hunch you are going to try to get us to use automake.)

This is totally unfounded FUD. Where did I said or post something
remotely related to automake? Those targets I've added are just to
enable the proper regeneration of the autoconf files. With these targets
you can edit configure.in and just type "make".

> * configure.in: I see no reason why gettext needs us to define PACKAGE or
> VERSION.

So that we can just use the unmodified Makefile.in.in file.

> * po/Makefile.in.in: We're not using automake, so we need to construct
> our own
> customized Makefile.in.

That's bogus.

> * subversion/*.c: We do not protect includes of svn_private_config.h
> as it is
> always available (even on Win32).

Well... is autoconf tradition. I suppos that it's like that so that you
can take out any file and compile in other environment without worrying
of the missing config.h file.

IMO you have yo have a very good reason for, in a project already using
autoconf, discarding all the already made infrastructure. I haven't read
a valid reason so far. These kind of things make the life of new
developers more miserable... IMHO of course. =)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 30 20:11:21 2004