Re: Patches for OS/2 (1)

[Andreas Buening]

Bruno Haible wrote:
> 
> 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.

This is known but it's better than having no working configure.

[PATH_SEPARATOR]


> > Please provide a Makefile.am for the intl subdirectory.
> 
> No, an automake generated Makefile.in is not suitable here.

Why not? The current Makefile.in looks as if it had been generated
by an older automake.


> > 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.

>From the autoconf manual:

Preset Output Variables
-----------------------

[CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS, ...]

 - Variable: LIBS
     `-l' options to pass to the linker.  The default value is empty,
     but some Autoconf macros may prepend extra libraries to this
     variable if those libraries are found and provide necessary
     functions, see *Note Libraries::.  `configure' uses this variable
     when linking programs to test for C, C++ and Fortran 77 features.

[...]

So LIBS is a documented feature. As soon as you implement silly
features there are silly people like me who use them and rely on
the docs.

> It is wrong to make libintl depend on additional libraries.

LIBS might be used to add extra libraries that extend the libc of
the system. You may have noticed that Andrew Zabolotny (the former
OS/2 porter) had written a libiconv wrapper for the OS/2 NLS API.
If I want that gettext uses that lib I use LIBS="-luse_native_iconv"
so that configure doesn't even try to find any other silly libiconv
that might be available.

If a feature like LIBS is documented then I assume that any
core GNU tool (i.e. autoconf, automake, libtool and gettext) takes
care of it. If this is not the case (and gettext is used by a _lot_
of other packages) then I can't trust on this behavior and I'd better
use LDFLAGS for this purpose for _every_ package, even if the LDFLAGS
docs in the autoconf manual tells me NOT to put extra libs into
LDFLAGS but into LIBS:

- Variable: LDFLAGS
    Stripping (`-s'), path (`-L'), and any other miscellaneous options
    for the linker.  Don't use this variable to pass library names
    (`-l') to the linker, use `LIBS' instead.  If it is not set in the
                              ^^^^^

Generally, all changes to the automake output (i.e. Makefile.in)
are there due to a reason. So I ask you to either recreate the
intl/Makefile.in from a current automake version or to add missing
features by hand to intl/Makefile.in.

[snip]


> > 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.

Great deal. Most packages don't work out of the box for OS/2. As soon
as I add a line to configure.ac or I just rerun autoconf to update
configure to a working version all other files want to be updated.
Btw. is ls -n (use UID instead of username) not standardized?


> > 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.

Thanks.


> > 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.

But there could be at least some kind of message by configure that the
prefix/share/aclocal directory is for aclocal.


> > 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".

The user doesn't even know that the prefix/share/aclocal directory
is from gettext. A lot of people just install software in their home
without checking every directory and file whether it might have been
installed by the latest "make install".


> 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.

But doing a test installation just to see which extra directories
are installed by "make install" and looking into some Makefiles to find
out which undocumented variable controls this behaviour can't be the
solution.


Bye,
Andreas