Re: gettext-0.14.2: suggestions to ease gettextization + a few bugs

[Bruno Haible]

Hello Alexandre,

>  >> You can use `EXTRA_DIST = m4/ChangeLog' in the top-directory to
>  >> distribute the ChangeLog, like you do for files in tools/.
> 
>  Bruno> Oh yes, I wouldn't have noticed this pitfall: A
>  Bruno> ChangeLog file gets distributed automatically, but an
>  Bruno> m4/ChangeLog file doesn't! Thanks for the reminder.
> 
> Maybe Automake should distribute automatically the "common
> files" (i.e. those files displayed by automake --help) for
> directories listed in AC_CONFIG_AUX_DIR and AC_CONFIG_MACRO_DIR?

Maybe. For people who think "automake distributes ChangeLog etc.
for those directories where there is a Makefile.am", this behaviour would
be one more surprise. For people who think "automake distributes ChangeLog
etc. for the directories related to autoconfiguration" it would be one
surprise less. Hard to tell which perspective is the more correct one.

> >   Personally I prefer one global ChangeLog per package so likewise I
> >   wish gettextize would not create m4/ChangeLog if none already exist.
> 
>  Bruno> The location of the ChangeLog files depends on the size
>  Bruno> of the package and the taste of the maintainer. This is
>  Bruno> one of the things gettextize cannot guess. And
>  Bruno> introducing a command line option just for this? Hardly
>  Bruno> worth it.  The maintainer can copy the piece of
>  Bruno> ChangeLog from one file to another if he desires to do
>  Bruno> so.
> 
> Not only copy the contents, but also delete the file, and remove
> it from the Makefile.am.  One each upgrade.  Quite tiresome :(
> 
> What's wrong with assuming that if 
>    1) m4/ already exists, and
>    2) m4/ does not have a ChangeLog
> then the maintainer do not want one?
> 
> Obviously if m4/ did not exist, you cannot guess, and I agree
> this isn't worth an option.  But if m4/ already exists you don't
> even have to guess: just look whether there is one or not.

Agreed and implemented. It is evident that you have more experience in
writing wizards for developers than I do. Thanks for the advice.

> Maybe paste the two above paragraphs as comments in po.m4?  I
> really couldn't have guessed the rationale by looking at the
> code.

Done.

>  >> * If configure.ac has AC_CONFIG_AUX_DIR([tools]) and the tools/
>  >> directory does not exist, gettextize should create it before trying
>  >> to copy config.rpath and mkinstalldirs.  Just like it does for m4/.
> 
>  Bruno> I don't agree. If configure.ac has
>  Bruno> AC_CONFIG_AUX_DIR([tools]) then the maintainer is
>  Bruno> responsible for having created this directory.
> ...
> Presently, autoreconf will create the AC_CONFIG_AUX_DIR
> directory if it does not exist.  I'm going to change automake so
> it does it too (for the sake of people not using autoreconf),
> because it is just easy to do and useful.
> ...
> It's not needed there because autoreconf is always used, and
> autoreconf creates the directory when it is missing.
>
> It's needed with gettextize, because gettextize has to run
> before autoreconf.
> [...]

The line between helping a developer (by not frustrating him) and
encouraging developer sloppiness is thin.

But anyway, for consistency with autoreconf and automake, I have no other
choice than doing the same.

>  >> Also note that the Gettext FAQ says to include gettext.h, and then
>  >> to mark strings with _(), but it does not say to define _().
> 
>  Bruno> To which FAQ are you referring? 
> 
> Sorry, I was referring to gettext-tools/doc/FAQ.html.  The answer
> to question "How do I make use of gettext() in my package?"

Thanks. I was accidentally looking at an older copy that didn't have this
question.

>      * Mark all strings that should be translated with _(), like this:
>        _("No errors found."). While doing this, try to turn the strings
>        [...]
> 
> The second point actually suggests to use _(), so people may
> expect this to be defined somewhere.

Oops, yes, I forgot to mention that people need to add
  #include "gettext.h"
  #define _(string) gettext (string)
in every source file that uses translatable strings. Thanks for having
noticed it!

>  >> * The comment of MSGID_BUGS_ADDRESS in po/Makevars.template should
>  >> really state that it defaults to $(PACKAGE_BUGREPORT), the third
>  >> argument of AC_INIT.
> 
>  Bruno> I don't think this would be appropriate: It would only
>  Bruno> invite the maintainers to not think about the issue (to
>  Bruno> which mailing list or alias they want the
>  Bruno> msgid-bugreports be mailed).
> ...
>   1) is the current undocumented default a feature we can rely on?
>   2) is the definition of PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@ in
>      Makefile.in.in something that will stay there?

Both are undocumented details, but of course I'll think twice before
changing them.

> if the answer to 1) is no, people can still say 
>   MSGID_BUGS_ADDRESS = $(PACKAGE_BUGREPORT)
> unless the answer to 2) is also negative.

This is probably safe.

>  Bruno> This happened because I wanted to include the fixes of 'missing' and
>  Bruno> 'mdate-sh' that were done in 1.9.5, but at the same time wanted to
>  Bruno> minimize other risks one day before release. 
> 
> Amusingly the change I considered the more risky here were
> precisely those of `missing' and `mdate-sh' :)

And indeed I verified that your mdate-sh changes were working, before I
copied it from automake-1.9.5 :)

>  Bruno> I don't expect incompatibilities between automake-1.x.y and -1.x.z.
> 
> That's really OK for the public interfaces (i.e., the
> Makefile.am, the Makefile rules, the scripts options, etc.), but
> it's totally unwarranted for the implementation details.  The
> way scripts, Makefile.ins, and m4 macros interact are
> implementation details, and you cannot mix different versions of
> these and expect things to work.

Why does then
  AC_DEFUN([AM_AUTOMAKE_VERSION], [am__api_version="1.9"])
not include the subminor version? And why does then "automake -a"
create symbolic links to files inside a .../automake-1.9/... directory
that does not include the subminor version?

I would find it good if you could avoid breaking even internal APIs
beween automake-1.x.y and -1.x.z. This would make such errors as
"This file was generated by automake-1.9.4 but you have automake-1.9.5"
superfluous. (I don't remember the exact error message; probably it was
'aclocal' saying this.) When I want to change and build GNU packages,
I need to have a copy of each minor version of automake ready to use.
This is already tedious enough; requiring a copy of each _subminor_
version of automake is even worse.

> For instance you cannot use py-compile from Automake 1.9.3 with
> Makefiles generated by Automake 1.9.4, because fixing a bug
> required to change part of the interface between this script and
> the Makefile.

In such situations, I'd have hoped that either the bugfix is postponed
or the change is made in a compatible way.

>  Bruno> Yes, the documentation is one of the two reasons why I
>  Bruno> cannot assign the version number 1.0 to GNU gettext :-(
> 
> Now you have teased my curiosity.  May I ask what is the other reason?

libintl is not multithread-safe, if different threads are using different
locales simultaneously...

> Here is a 20th point, to make an even count:
> 
> * gettext-tools/TODO says that Perl, Shell scripts, and Scheme
>   are not supported, while the top-level NEWS says they are!

Fixed: I've removed this obsolete TODO file.

Bruno