bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patches for OS/2 (1)


From: Bruno Haible
Subject: Re: Patches for OS/2 (1)
Date: Mon, 5 May 2003 12:10:02 +0200 (CEST)

On Wednesday 13 November 2002, Andreas Buening wrote:

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

OK, this is an argument. But $(LIBS) has to be mentioned on the link
command line _after_ the .o files, whereas $(LDFLAGS) usually comes
_before_ the .o files.

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

That's convincing enough that I've added $(LIBS) to intl/Makefile.in.
But it would be cleaner if either
  - Andrew Zabolotny's library were called usable with "-liconv",
    this would mean no changes to iconv.m4 are needed, or
  - if it is called differently, you provide an iconv.m4 patch that will
    make use of this library if present and if the "real" libiconv
    is not found.

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

No I don't want to recommend that people use "aclocal -I $prefix/share/aclocal"
because that's not a command they can easily put into their Makefiles.
Instead I recommend "aclocal -I m4", and therefore it is irrelevant to
the user where the .m4 files have been installed.

> The user doesn't even know that the prefix/share/aclocal directory
> is from gettext.

He doesn't need to know. All he needs to know about is "gettextize"
and "autopoint".

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]