Re: Makefile.in.in fails when gettext not installed (patch)

[Yann Dirson]

On Fri, Sep 10, 2004 at 09:56:37PM +0200, Bruno Haible wrote:
> Yann Dirson wrote:
> > for some user fetching from
> > CVS, for example, there may not be any .gmo files available.  And the
> > current rules can just prevent "make" to reach the src/ dir because of
> > the error thrown by this line.
> 
> That depends how many files you have committed to CVS. In general, the
> more generated files you commit into CVS, the fewer tools the CVS user
> needs to have. (Please read also the section "Integrating with CVS" of the
> GNU gettext manual.) In particular, if you put the .pot file under CVS
> control, the CVS user won't need to have the gettext tools installed.

Damn, this section is not in the version at
http://www.gnu.org/software/gettext/manual/.  It would be good to have
the version of gettext to which the doc relates, early in the doc, so
that we can quickly notice whether it is outdated.

In wesnoth we currently have most files committed, but not gmo files.
But having them in cvs would not solve the problem, because of the
alphabetic order used by cvs, and the subsequent timestamps on "cvs
update" - they would be seen as outdated after an update.

Besides, do you see any problems induced by the change I suggest ?


Some remarks about the version I have locally (current Debian package
for 0.14.1):

- in 12.6.2, a major drawback IMHO of the 1st option is that when devs
do not all use the same version of all of autoconf, automake, libtool,
gettext (do I forgot any ?), a 1-line change in configure.ac can
result in a 6000-line diff.  That just kills the usefulness of version
control as a tool for tracking changes.  Also, as mentionned for the
2nd one, spurious conflicts on those generated files are very frequent.

- for the 3rd option, you may want to mention that most projects
making this choce use a script, commonly named autogen.sh, to make
this as painless as possible.

> > BTW, throwing stderr from these tests to /dev/null is quite annoying, since
> > the reason for the test failure is not kept anywhere. It would be
> > good to have it reach config.log, that would help diagnosing user
> > problems
> 
> Agreed. It's too much of a black box test. - How do I print something into
> the config.log? I don't find it mentioned in the autoconf manual.

AC_MSG_CHECKING does this, and is implemented as:

m4_define([AC_MSG_CHECKING],
[_AS_ECHO([$as_me:$LINENO: checking $1], AS_MESSAGE_LOG_FD)
_AS_ECHO_N([checking $1... ])[]dnl
])


According to the expanded form, the 1st line (with AS_MESSAGE_LOG_FD)
does the thing.  Looks pretty internal.

Many other parts of the macros use a >&AS_MESSAGE_LOG_FD redirection.

-- 
Yann Dirson    <address@hidden> |
Debian-related: <address@hidden> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>