[ On Thursday, September 20, 2001 at 01:07:50 (-0500), Frederick Bruckman wrote: ]
> Subject: Re: configure.in patches in a pkg
>
> 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.

Yes, but not every configure.in uses only tests that honour ac_cv_*
settings, or deal with them properly, and therein lies the problem.
Indeed in some cases this very problem resides in the broken tests which
we currently have to patch around.

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

I was actually considering forcing all the values to known values, and
using simpler and more specific tests in the sourced CONFIG_SITE script
to account for platform differences, etc.  This way you effectively
disable all the ac_cv_* compatible tests.  Indeed in any cases where
incompatible changes can still be controlled by pre-set variables these
too can be included in the CONFIG_SITE script.

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

I think you misunderstand.  I don't mean having one CONFIG_SITE file for
a given target system, or even just one for all packages -- rather I
mean having a specific CONFIG_SITE file created for every package (that
uses autoconf).  I think doing this eliminates all of the previous
concerns with the viability of a single master CONFIG_SITE file (at the
expense of a wee bit of extra work in the maintenance phase, much of
which can be automated for the straight forward cases).

Clearly the initial creation of a complete CONFIG_SITE file can be
mostly automated.  For packages which stick to strict autoconf common
tests, and especially those which have no depedencies, will require no
further work at all.  Pkgsrc maintainers would simply generate an
example config.cache file and then run a script on it to turn it into a
usable CONFIG_SITE file.

> The standard configure tests for operating system
> features work fine, it's the custom ones that cause problems.

Yes, often that's the case -- but those custom tests are also the ones
that commonly ignore or mis-handle ac_cv_* settings (and indeed
sometimes even request manual interaction!).  If the configure script is
to be run by the pkgsrc build then there are cases where patching
configure.in is unaviodable.

And then there are all the wasted cycles of revisiting these common
tests on every build on every system everywhere....

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

I'm now thinking more along the lines of a dynamic per-package
CONFIG_SITE that could easily account for the ongoing minor changes in
NetBSD (along with platform sepecific variances and of course the pkgsrc
controlled features such as $PREFIX et al) but which would fix all the
major test results as appropriate for NetBSD in general.

The other advantage is of course that forcing all the test results gives
an enormous boost in performance!  Think of how much time would be saved
over and over again by every user of a sun-3 or vax, for example!  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>