bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some questions about gettext


From: Thomas Vander Stichele
Subject: Re: some questions about gettext
Date: Fri, 09 Jan 2004 18:41:16 +0100

Hi Bruno,

Thanks for getting back so quickly.


> > I would prefer to go with b) as a first try.  I set up a complete
> > skeleton tarball with a simple source app that contains strings.
> 
> You can also look at the 'examples/hello-c/' subdirectory installed by
> gettext 0.13.1.

I will take a look at that.  Currently I have 0.12.2 installed in Fedora
Core 1, but will look at the source.

> > I have two problems with this skeleton tarball:
> > a) There is no mechanism for me to put values substituted by
> > config.status (Ie, AC_SUBST's) in Makevars.
> 
> Yes, this is not supported. All the values (DOMAIN, COPYRIGHT_HOLDER, etc.)
> are expected not to change except by explicit maintainer action.

> Alexandre Duret-Lutz and I are working on improvements that would solve
> this problem.

OK.  For now I'll keep the patching around then.

> > b) distchecking the tarball fails in the intl/ dir.  The nonsrcdir build
> > fails to find the source files needed to build the objects.
> 
> Strange: intl/Makefile.in has a VPATH line that should take care of this.

How does that work ? grepping the file for VPATH or vpath didn't turn up
anything.  BTW, I seem to recall that make distcheck with latest
automake now does both a VPATH and DESTDIR test, ie two
install/uninstall tests.  Don't know if that's related or if I'm
paraphrasing correctly.

On an unrelated note, maybe it would be nice if it could detect automake
is being used and just generate a Makefile.am instead ?


> Btw, VPATH is only supported with GNU make. Other 'make' implementations
> don't support VPATH.

Well, that'll be their loss then :)

> Anyway, if you use AM_GNU_GETTEXT([external]) you avoid carrying around
> the entire intl/* sources with your package, and it also fixes this
> problem.

True.  any drawbacks to that ?

> > However, I'd like your opinion on the first two problems.  Also, I'd
> > like an opinion on whether I should use autopoint, or stick with
> > gettextize and commit huge chunks of generated code to CVS.
> 
> It depends on what tools the people who work off the CVS have installed.
> If you want them not to need autoconf, automake, autopoint etc. installed,
> you have to regularly commit huge amounts of autogenerated code to CVS.

Well, I was more thinking about the problem where I on Fedora have one
version, and someone else on debian a different one, and it's impossible
to get it to work for both.  We feel that the problem you state, if
developers have tools or not, is one for developers.  We expect our
developers working on CVS to have the full autotool suite installed.

> Also remember: gettextize is a migration tool from one gettext version
> to the next, whereas autopoint is for regenerating files automatically.

Yeah.  Personally, I'd like to stick with autopoint, since it's more in
line with the rest of the autotools' use.

Thanks for the explanation.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
If you ain’t there
ain’t nobody else to impress
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/






reply via email to

[Prev in Thread] Current Thread [Next in Thread]