From:	"Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
Organization:	Darmstadt University of Technology
To:	Bruno Haible <haible AT ilog DOT fr>
Date:	Sat, 10 Mar 2001 19:14:49 +0200
MIME-Version:	1.0
Subject:	Re: gettext pretest available
CC:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
In-reply-to:	<15017.19621.800332.788802@honolulu.ilog.fr>
References:	<343878750F9 AT HRZ1 DOT hrz DOT tu-darmstadt DOT de>
X-mailer:	Pegasus Mail for Windows (v2.54DE)
Message-ID:	<439E9106868@HRZ1.hrz.tu-darmstadt.de>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Fri, 9 Mar 2001 22:35:33 +0100 (CET), Bruno Haible wrote:
> > diff -acprNC3 gettext-2001-02-05.orig/intl/libgnuintl.h gettext-2001-02-05/intl/libgnuintl.h
> > *** gettext-2001-02-05.orig/intl/libgnuintl.h	Tue Feb  6 12:58:40 2001
> > --- gettext-2001-02-05/intl/libgnuintl.h	Tue Feb 27 22:40:34 2001
> > ***************
> > *** 39,44 ****
> > --- 39,53 ----
> >   # endif
> >   #endif
> >   
> > + #ifdef __DJGPP__
> > + /* This will remove the conflict between the gettext function
> > +    from libintl.h and DJGPP's gettext function from conio.h.
> > +    GNU gettext takes *always* precedence over DJGPP's _conio_gettext. */
> > + # undef   gettext
> > + # define  gettext gettext
> > + # define  __LIBINTL_H_INCLUDED__
> > + #endif /* not __DJGPP__ */
> > + 
> >   #ifdef __cplusplus
> >   extern "C" {
> >   #endif
>
> Done, except that I don't see the need for __LIBINTL_H_INCLUDED__. You
> have _LIBINTL_H, you have __USE_GNU_GETTEXT. You don't need a third
> macro.
The choice of __LIBINTL_H_INCLUDED__ was not arbitrary. With the above code,
I am introducing a libintl.a dependency into DJGPP's libc.a. If in the future,
a GNU maintainer of GNU gettext decides to rename _LIBINTL_H or to remove
__USE_GNU_GETTEXT at all, then DJGPP's libc.a will become automatically broken.
Can you guarantee that this will never happen?.
I expected to minimize the impact of future GNU gettext changes in DJGPP's
libc.a by introducing a DJGPP specific macro.
Anyway, I will use _LIBINTL_H and resend appropiate patches for DJGPP's CVS tree.


> > *** gettext-2001-02-05.orig/Makefile.am	Mon Feb  5 18:38:02 2001
> > --- gettext-2001-02-05/Makefile.am	Sat Mar  3 18:23:24 2001
> > *************** gettextsrcdir = $(datadir)/gettext
> > *** 26,32 ****
> >   gettextsrc_DATA = ABOUT-NLS
> >   
> >   EXTRA_DIST = BUGS DISCLAIM README.gemtext aclocal.sh
> > ! SUBDIRS = doc intl lib src po m4 misc tests
> >   
> >   ABOUT-NLS: $(srcdir)/doc/nls.texi $(srcdir)/doc/matrix.texi
> >   	rm -f $(srcdir)/ABOUT-NLS \
> > --- 26,32 ----
> >   gettextsrc_DATA = ABOUT-NLS
> >   
> >   EXTRA_DIST = BUGS DISCLAIM README.gemtext aclocal.sh
> > ! SUBDIRS = doc intl lib src po m4 misc tests djgpp
> >   
> >   ABOUT-NLS: $(srcdir)/doc/nls.texi $(srcdir)/doc/matrix.texi
> >   	rm -f $(srcdir)/ABOUT-NLS \
>
> I didn't take this patch, because I don't like the idea that on all
> Unix platforms the build descends into the djgpp/ subdirectory. (That
> could become dangerous if this directory is not maintained regularly.)
> Instead I put a simple Makefile without autoconf machinery into djgpp/.
My implementation of djgpp/Makefile.am was identical to the implementations
used in the GNU distributions of grep, sed, textutils, fileutils, shellutils,
texinfo and may be some others more. All the mentioned packages offer out-of-
the-box DJGPP support and use a djgpp/Makefile.am to update the djgpp
specific files. I assumed that the same mechanism would be ok for GNU gettext
too. Anyway, If you prefer something different, it will be ok for me as long
as your solution DTRT.

Regards,
Juan Manuel Guerrrero

- Raw text -