Re: CVS & Gettext

[Akim Demaille]

Hi Bruno!

| Akim Demaille writes:
| > My question is probably a bit stupid, but, I'm a bit lost with the
| > current content of Gettext.  Before, it was simple: intl/ is not to be
| > put under CVS for a given project, since it's brought by gettextize.
| > Therefore, just cvsignore the whole intl/.
| 
| Ignoring intl in CVS is IMO a bad advice, because:
| 
| * gettextize is a migration tool. It automates about 80% of the
|   migration from one gettext version to the next one. In earlier
|   gettextize versions (prior to 0.11) the percentage was about 50%.
|   But anyway, after running gettextize, some things have to be
|   adjusted manually by the maintainer. gettextize reminds the
|   maintainer of most of these. Some other reminders are to be found
|   in the gettext documentation.

I understand this point of view.  Nevertheless, the fact that there
remains things to adjust in the code is related to the code itself,
not intl and other po files.  Once a configure.ac upgraded, once a
Makefile.am upgraded, it is done, and there is no need to do it again.

| * The migration from one gettext version to the next one may also
|   involve changes in Makefile.in/am and configure.in. If you don't
|   put the intl directory in CVS but leave it to each developer
|   to generate it, the version mismatches will be *very likely*.

Indeed.  But people using CVS projects are well aware of these issues
with the other components of the GNU Build System.

| You may be irritated by the recent autoconf-2.53 which contains a
| program ('autoreconf') which runs gettextize along with automake and
| autoconf.

I'm quite happy with it, thanks!  It provides what many people are
demanding, some unifying interface to the GNU Build System.

| This tool is simply buggy and broken.

Sorry about its problems, I'll report them to the maintainer.

| It should never run
| gettextize automatically, because it has no way to do the remaining
| 20% of the job, which gettextize doesn't do.

Fortunately, it does not.  Just as in the case of Gettext, reading the
documentation can be helpful to know what it does.  If you don't
--install, it will never do such a thing.  If you have Gettext
installed and you don't --force, it won't either.


There is strong demand for such a tool, and it is quite successful in
this task.  The only problematic problem is that gettextize doesn't
check if intl/Makefile is already in configure.in before adding it.

Would you accept a patch to gettextize that would make sure gettextize
does not change something it should not?  I mean, even as a transition
tool, when I used 0.10.40, I already had intl in SUBDIRS, and
intl/Makefile in the output files.  In this case, it nevertheless
breaks my sources.


| > Now, there seems to be several gettextize files in po/ too:
| > 
| > ? po/Makevars.template
| 
| This file is created by gettextize for the maintainer's sake, with the
| recommendation of removing it once the maintainer is done with
| migrating.

Yep, indeed, thanks.

| > ? po/Rules-quot
| > ? po/boldquot.sed
| > ? po/address@hidden
| > ? po/address@hidden
| > ? po/insert-header.sin
| > ? po/quot.sed
| > ? po/remove-potcdate.sin
| 
| These are package independent files which belong in CVS, just like
| Makefile.in.in and intl/*.

Thanks for explaining!

| > ? po/remove-potcdate.sed
| 
| This file goes away by "make distclean" and is therefore a good
| candidate for .cvsignore.

Thanks, I appreciate your help.