On Thu, 20 Sep 2001, Greg A. Woods wrote:

> [ On Wednesday, September 19, 2001 at 20:49:22 (-0500), Frederick Bruckman wrote: ]
>
> > 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
> > x11/xscreensaver:
> >
> > CONFIGURE_ENV+= ac_cv_x_app_defaults="${X11PREFIX}/lib/X11/app-defaults"
> >
> > On my system, "configure" says
> >
> > checking for X app-defaults directory... (cached) /usr/X11R6/lib/X11/app-defaults
>
> I'm not sure you really want to go down that route either, but
>
> There's no telling that every configure script will correctly obey all
> those ac_cv_* things, and indeed there's no pre-defined canonical list
> of them anywhere.

It will, because that's what configure does. It sources config.cache,
then always tests those ac_cv_* things before even running the
particular configure test that would set them. The fact that there's
no pre-defined list is irrelevant. Once you zero in on a problem test
in the configure script, you can always neatly force it your way -- no
patches, no headache, no concerns about autconf.

> Not to mention how big the potential necessary set might add up to!

What? It's one line of Makefile for 5-10 lines of patch.

There's no "magic bullet" that'll make every program just work on
NetBSD without any effort. It's just another trick of the trade, but
it's an elegant solution in many cases.

> However you can feed these definitions to configure without having to
> put them in the environment using the CONFIG_SITE feature:

That would be simply wrong, because as you said, there's no
cannononical list. The standard configure tests for operating system
features work fine, it's the custom ones that cause problems.
Moreover, CONFIG_SITE for the standard tests has been discussed and
ruled out, because of the great variety of systems that pkgsrc
supports, and the fact the "-current" users would be required to
update ${CONFIG_SITE} frequently.

Frederick