Re: Patches for OS/2 (1)

[Bruno Haible]

Andreas Buening writes:

> First, I have some notes to the configure process:
> 
> m4/progtest.m4 can't find executables (due to their ".exe" extension
> and because PATH uses ';' rather than ':'). I used PATH_SEPARATOR which
> is defined since autoconf 2.5x and ac_executable_extensions which
> enables ".exe" support in autoconf since 2.53 (?).

OK, I'm changing AM_PATH_PROG_WITH_TEST like this. But
ac_executable_extensions is not fully implemented: nothing in the
configure file sets it. This means that you have to set it yourself in
your config.site.

> I added PATH_SEPARATOR to config.h so that no #ifdef's are
> necessary for this.
> 
> ---------------------------
> --- old/gettext-0.11.5/configure.in     Tue Aug  6 13:54:56 2002
> +++ gnu/gettext-0.11.5/configure.in     Sun Oct 13 21:48:36 2002
> @@ -234,6 +234,10 @@
>  changequote([, ])dnl
>  AC_SUBST(LTALLOCA)
> 
> +AC_DEFINE_UNQUOTED([PATH_SEPARATOR],
> +  ['${PATH_SEPARATOR-:}'], [Define to ':' or ';']
> +)
> +
>  AC_OUTPUT([Makefile \
>             lib/Makefile lib/javacomp.sh lib/javaexec.sh \
>             intl/Makefile intl-java/Makefile \
> ---------------------------

This is wrong in two ways:
1. It breaks when crosscompiling.
2. Stuff needed by intl/* belongs into gettext.m4, not configure.in.

> Please provide a Makefile.am for the intl subdirectory.

No, an automake generated Makefile.in is not suitable here.

> Otherwise odd patches like that one below are necessary:
> 
> ---------------------------
> --- old/gettext-0.11.5/intl/Makefile.in Thu Jul 25 12:49:56 2002
> +++ gnu/gettext-0.11.5/intl/Makefile.in Sat Oct 19 20:39:38 2002
> @@ -55,7 +55,8 @@
>  -DLIBDIR=\"$(libdir)\" -DIN_LIBINTL @DEFS@
>  CPPFLAGS = @CPPFLAGS@
>  CFLAGS = @CFLAGS@
> -LDFLAGS = @LDFLAGS@
> +LIBS = @LIBS@
> +LDFLAGS = @LDFLAGS@ $(LIBS)
> 
>  COMPILE = $(CC) -c $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) $(XCFLAGS)
> 

This doesn't make sense. Read in the autoconf manual what $(LIBS)
stands for. It is wrong to make libintl depend on additional libraries.

> @@ -294,7 +295,7 @@
> 
> 
>  mostlyclean:
> -       rm -f *.a *.la *.o *.lo core core.*
> +       rm -f *.a *.la *.o *.obj *.lo core core.*
>         rm -f libintl.h charset.alias ref-add.sed ref-del.sed
>         rm -f -r .libs _libs
> ---------------------------

Thanks, added.

> I also had to update doc/mdate-sh because the output of "ls" has less
> columns on OS/2.
> 
> ---------------------------
> --- old/gettext-0.11.5/doc/mdate-sh     Fri Jun 16 07:49:22 2000
> +++ gnu/gettext-0.11.5/doc/mdate-sh     Sun Oct 13 20:46:04 2002
> @@ -35,8 +35,8 @@
>  # The month is at least the fourth argument
>  # (3 shifts here, the next inside the loop).
>  shift
> -shift
> -shift
> +#shift
> +#shift
> 
>  # Find the month.  Next argument is day, followed by the year or time.
>  month=
> ---------------------------

Will not work for Unix users whose name is "Jun" or so. Anyway
mdate-sh is only used by the maintainer, so it doesn't matter if it
works on OS/2.

> After that, I have some general notes about the current gettext:
> 
> 1) Something that was driving me nuts: When configure checks for an
>    existing libintl it prints messages like
>    checking for msgfmt... /usr/bin/msgfmt
>    but there is no message that informs the user about the final
>    decision whether the internal or the external gettext will be used
>    or even none of them.
>    The worst case happened when out admins upgraded our Linux PC's
>    partially. The executables of the gettext package had different sizes
>    when compiled on different machines and NLS worked differently on
>    those systems. So I had no clue why it worked for that PC but not
>    for the other one. Please, add a AC_MSG_NOTICE([using internal gettext])
>    or something like that.

Good idea. I'm adding such a message to AM_GNU_GETTEXT.

> 2) aclocal files are installed into prefix/share/aclocal without
>    any further notice. If I haven't installed aclocal at the same
>    location these files are completely useless for me.

The main use of these *.m4 files is through gettextize and autopoint.
Given the versioning problems through steadily changing autoconf I
don't know whether it is a wise idea at all to use them through
"aclocal"'s implicit directory. I recommend "aclocal -I m4" instead.
This way, other developers using the same package will get the same
*.m4 files.

> 3) There is no option to change aclocaldir and docdir by a configure
>    option. Please add --with-aclocaldir and --with-docdir to the options.
>    E.g. the File Hierarchy Standard requires additional docs to be installed
>    into prefix/share/doc, not prefix/doc. Fiddling around with make
>    options "make install docdir=/usr/local/share/doc/gettext" is nasty
>    as well as unexpected.

There is no need for changing aclocaldir; the user can use
"aclocal -I $prefix/share/aclocal".

About docdir, such an option would make sense as a standard Makefile
target, that would be supported by autoconf, automake etc. However,
the issue seems stuck, unfortunately, because people don't agree which
is the right standardization body for this kind of things.

Bruno