In article <1102881201.2786.143.camel@lister.bodgit-n-scarper.com>,
	matt@bodgit-n-scarper.com (Matt Dainty) writes:
> Is there a way to prefer the pkgsrc xgettext binary over the system one?
> I have the gettext 0.11.5 installed from pkgsrc, but the configure
> script of some pkgsrc packages I'm trying to create is detecting the
> system gettext 0.10.35 binaries and issuing the following error:
> 
> checking for msgfmt... (cached) /usr/bin/msgfmt
> checking for gmsgfmt... /usr/bin/msgfmt
> checking for xgettext... (cached) /usr/bin/xgettext
> checking for msgmerge... (cached) /usr/bin/msgmerge
> found xgettext program is not GNU xgettext; ignore it

In general, you would add XGETTEXT=${LOCALBASE}/bin/xgettext to 
${CONFIGURE_ENV}, same for ${GMSGFMT}, ${MSGFMT}, and ${MSGMERGE}.

> I'm running a fairly recent pkgsrc checkout on a NetBSD 2.0RC5 system,
> some of these packages don't have configure scripts, etc. so I'm using
> the various tools as installed by pkgsrc; autoconf, gettextize,
> libtoolize, etc.

Don't forget to include the macros to get all the proper dependencies...,
and to re-write your package everytime GNU autotools includes a backwards
incompatible change.

If the package doesn't include a configure script, how does it usually
build? Consider accomodating its native build system, and avoid all the
autotools hassles that will no doubt be compounded by the fact that the
upstream maintainer doesn't support them.  For examples of how to get by
without GNU autotools, take a look at "kermit" or "gkrellm".


Frederick