Re: gettext: gnulib update; less automake warnings

[Bruno Haible]

Ralf Wildenhues wrote:
> So I can convince you by sending a bug report?  Would it suffice if
> I changed the Subject: of this mail to `bug in gettext:...'?  ;-)

;-)

> there is the UnixWare 2.03
> compiler suite, for which there was a relatively recent bug report:
> http://lists.gnu.org/archive/html/libtool/2005-10/msg00063.html

That was a bug report about UnixWare 2.03, which according to
http://de.wikipedia.org/wiki/UnixWare was released in 1995 - more than
10 years ago. Once in two or three years there is also someone who
reports interoperability problems with Linux libc5 ! - I classify such
systems as museum exhibits.

> Even if I told you that I just
> introduced AC_PROG_CXX_C_O a few months ago, and plan to introduce
> AM_PROG_{CXX,F77,FC}_C_O too for consistency?

C++ is different. The various C++ compilers are generally less adhering
to standards than C compilers. But it doesn't apply to gettext, since
gettext uses the C++ compiler only on Woe32.

> For C and C++, there is MSVC, which uses /OUT, if you don't happen
> to use a compiler wrapper such as cccl.

Umm, how does this relate to whether I should use AM_PROG_CC_C_O or
not? I mean, if a future version of automake supports MSVC without a
wrapper script, and it cannot output a "-o" option, then it will
create rules that look like

msgmerge-foobar.obj: foobar.c
        $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(msgmerge_CPPFLAGS) 
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c @address@hidden `if test -f 'foobar.c'; 
then $(CYGPATH_W) 'foobar.c'; else $(CYGPATH_W) '$(srcdir)/foobar.c'; fi`

and have CC_OUT_OPTION being set to '-o ' on Unix systems and to '/out:'
with MSVC. Will I need to use AM_PROG_CC_C_O to get this CC_OUT_OPTION
set, although the .obj rule by itself is generated by automake without
me having asked for it?

> There is also a set of compiler wrapper scripts, most of which are
> not so commonly used any more, that has distinct problems with -c -o
> (some older MPI implementations shipped such scripts under names as
> mpicc); this is rather less relevant to gettext, though.

Indeed.

> Convinced now?

No...

> At least the change using AM_CPPFLAGS is so trivial 
> (and it makes for a smaller Makefile.in, too) that I don't see any
> reason not to apply it.

I would prefer putting a line into configure.ac than to force all
programs in a directory to use the same CPPFLAGS. Someday a program will
be added to the same directory which needs different CPPFLAGS.

Bruno