Subject: Re: configure.in patches in a pkg
To: None <firstname.lastname@example.org>
From: Frederick Bruckman <email@example.com>
Date: 09/19/2001 20:49:22
On Wed, 19 Sep 2001, Greg A. Woods wrote:
> What's worse though is that some patches in NetBSD's pkgsrc are not even
> created by autoconf -- they are manual hacks. This is BAD BAD BAD!!!!
In a sense, yes, but on the other hand, committing a patch to make it
exactly like the auto-generated file would be dumb, too, as you'd get
a 10k patch with no information (nothing but line number offsets).
> there are a large number of configure.in patch files in NetBSD's pkgsrc
> that are not done in ways appropriate to feed back to the package
> Besides, no assumption should ever be made that any such feedback will
> be acted upon -- that's the reason we have patch file support in the
> first place! ;-)
Point taken! Even when the author wants to help, and accepts a patch,
there's often some little thing that still needs to be hacked. The
whole "autoconf" paradigm is not pkgsrc-friendly: even packages that
build out of the box (with defaults) on NetBSD need patches for pkgsrc.
Here's my solution. It's amazingly easy to get the result you want out
of any particular configure test by simply pre-loading the
environment. Consider the following, from Makefile.common for
On my system, "configure" says
checking for X app-defaults directory... (cached) /usr/X11R6/lib/X11/app-defaults
On a system it with "xpkgwedge" installed, it will say
".../usr/pkg/lib/X11/app-defaults". It's foolproof. Moreover, I'm sure
we _don't_ want every configure script in the world to hard code a
search path which includes /usr/pkg/lib/X11/app-defaults (ptah), so
this is really the only way, barring patches which must be carried
forward and re-constructed forever and ever.