Re: Bug#114019 acknowledged by developer (Re: Bug#114019: gettextize will not preserve changes to po/Makefile.in.in, and has no way to be told of extra keywords for xgettext (fwd))

[Henrique de Moraes Holschuh]

On Thu, 01 Nov 2001, Bruno Haible wrote:
> Henrique de Moraes Holschuh writes:
> > Say what?!  It's a matter of sed'ing the po/Makefile.in.in after you copy
> > it, and this is not complex at all.
> 
> This sed-ing would work for the one particular wish you have about
> Makefile.in.in. Other people have different wishes, thus different

Yes.

> modifications: use of multiple domains in the same directory, special
> casing some languages, special targets for the maintainers, additional
> dependencies, etc.

That would require a change in the very way gettextize works, and I agree it
would be a lot more complex. Too complex to be pratical, in fact, although
maybe not too dificult using something akin to CVS to update the files.

> > I did not ask you to parse whatever makefile is in po/Makefile.in.in and
> > update that or magically figure out what the user wants. THAT would be too
> > complex.
> 
> But that would be the only action that solves more than your
> particular small problem.

Yes. However, I didn't know about the other problems, and I have no idea if
they are requesting extra functionality, or a removal of a current
limitation in gettextize (but which is supported by the gettext system
itself).

> > I already have to tell them to "forget the very idea of
> > supporting non-GNU gettext: tell people [SunOS/other users] to use
> > --with-included-gettext or you'll go insane"
> 
> gettext 0.10.36 and newer gets this right by default.

I suppose so. But upstream rarely uses up-to-date gettext (which is
something else that pisses me off).

> > "you should not keep the gettext-generated files on your cvs tree,
> > cvs is for non-automatically-generated files only", etc.
> 
> That's your personal opinion. As a matter of fact, in the gettext CVS,
> the gettext-generated files are in the CVS.

A lot more people agree with me in that instance, especially if they are
downstream and have to deal with merging new upstream releases into their
downstream CVS repository.  CVS can produce extreme breakage if you're not
careful when using -j -j to merge upstream branch changes into your own on
the automatically generated files.

Anyway, getting people to keep it out of CVS at least makes it a bit more
likely that they will use the most up-to-date gettext their distribution
supports.

> > This is a lot more messy than properly supporting such options in
> > gettextize, which is supposedly THE centralized place (script) where to keep
> > such knowledge
> 
> The centralized place for such knowledge is the Makefile.in.in itself,
> not the gettextize script.

Then please stress that out a lot more in gettextize documentation. The
current documentation (info gettextize, Debian gettext 0.10.40-1) actually
induces one to think that the files gettextize fiddles with need never be
touched...

  "Some files are consistently and identically needed in every package
  internationalized through GNU `gettext'.  As a matter of convenience,
  the `gettextize' program puts all these files right in your package."

and a bit more below:

  "One distinction between these two directories is that `intl/' is meant to
  be completely identical in all packages using GNU `gettext', while all
  newly created files, which have to be different, go into `po/'."

The idea that one should never touch intl/* is a damn good one, but it is
currently flawed.  If it would be too much of a hassle to effectively make
that true, such as by adding a AC_GETTEXTOPT macro that defines extra stuff
to be sent to the various gettext subsystems in intl/* instead of the
defaults you currently use, then please update the documentation.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh