[Top][All Lists]

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

Re: CVS & Gettext

From: Paul D. Smith
Subject: Re: CVS & Gettext
Date: 21 Apr 2002 20:45:13 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

%% address@hidden (Akim Demaille) writes:

  bh> That's very clear. And it's not the purpose of gettextize, which is
  bh> merely a migration tool.

  ad> I think I have understood that bit.  I'm saying `gettextize can be
  ad> more useful, with a simple change'.  I'm saying `that migration
  ad> tool can become more than a migration tool with a simple change of
  ad> paradigm: change the files if they appear to need it, not if some
  ad> other stimulus gave the impression they had to be updated'.

  bh> So let's work on a "gettextreconf" tool that you could invoke from
  bh> autoreconf.

  ad> Hm, it is not clear to me why a new tool would be needed, Bruno.
  ad> I'm just asking for grepping the files before updating them.  I
  ad> fail to see the need for something else.  A new tool is additional
  ad> burden on your shoulders, which is definitely not what I'm looking
  ad> for.

After spending the majority of the weekend working on upgrading GNU
make's woefully ancient and obscure auto-ization, I find I must agree
with Akim here.

I've also been bit by Gettextize re-adding the same information multiple
times to my config/Makefile.am, Makefile.am, and configure.in.

I realize that by its lights it's doing the right thing, since I haven't
checked in all the "extra" verbatim files that gettextize adds to my
system.  In particular, I didn't check in these files, which gettextize


 (BTW, in any case I think gettextize should be enhanced to not bother
  adding a Makevars.template file if it sees there is already an
  existing po/Makevars file, which there is in my source tree...)

Gettextize would also have updated my Changlog files, except I can
suppress this with the --no-changelog flag (thanks!)

Now, that is a boatload of files which I don't particularly care to have
in my source tree, since they're just verbatim copies of whatever is in
gettext anyway (similar to how I allow automake --add-missing to install
various files such as install-sh or whatever).

My personal preference would be, as Akim has suggested, to have
gettextize spend a little extra time to realize whether it really needs
to add anything to the existing Makefile.am files, etc.  Adding them
when they are already in there is clearly not correct (I realize that
you feel we are misusing the tool in the first place).

Failing that, if it is too complicated to get right, I would be happy
with a flag to gettextize, like --add-missing, which did nothing but add
missing files and didn't try to update any Makefile.am, configure.in, or
Changelog files--and also didn't complain if a file to be added exists
already (say I wanted a local copy of po/Makefile.in.in for some reason;
using -f is not what I want, but without that gettextize will just fail).

That would make things much simpler for me, as a package maintainer.


 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

reply via email to

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