[ On Wednesday, September 19, 2001 at 20:49:22 (-0500), Frederick Bruckman wrote: ]
> Subject: Re: configure.in patches in a pkg
>
> 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).

Exactly.  That's reason accounts for one of the "BAD"s I used!  ;-)

> The
> whole "autoconf" paradigm is not pkgsrc-friendly: even packages that
> build out of the box (with defaults) on NetBSD need patches for pkgsrc.

I couldn't agree more!  Autoconf's entire goal is antithetical to pkgsrc.

Autoconf configure scripts try to configure a package to meet the
current run-time state of a target system; while pkgsrc needs to work
within very controlled and carefully specified parameters that define
all aspects of a target package's configuration.  With pkgsrc you know
almost all of the configuration parameters beforehand, while autoconf
needs to discover them all anew with every new target build.

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

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

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

    If the environment variable `CONFIG_SITE' is set, `configure' uses
  its value as the name of a shell script to read.  Otherwise, it reads
  the shell script `PREFIX/share/config.site' if it exists, then
  `PREFIX/etc/config.site' if it exists.  Thus, settings in
  machine-specific files override those in machine-independent ones in
  case of conflict.

     Site files can be arbitrary shell scripts, but only certain kinds of
  code are really appropriate to be in them.  Because `configure' reads
  any cache file after it has read any site files, a site file can define
  a default cache file to be shared between all Autoconf-generated
  `configure' scripts run on that system.  If you set a default cache
  file in a site file, it is a good idea to also set the output variable
  `CC' in that site file, because the cache file is only valid for a
  particular compiler, but many systems have several available.

  [[ .... ]]

     You can set some cache values in the site file itself.  Doing this is
  useful if you are cross-compiling, so it is impossible to check features
  that require running a test program.  You could "prime the cache" by
  setting those values correctly for that system in
  `PREFIX/etc/config.site'.  To find out the names of the cache variables
  you need to set, look for shell variables with `_cv_' in their names in
  the affected `configure' scripts, or in the Autoconf `m4' source code
  for those macros.

We could try to provide a complete group of presets for every
autoconf'ed package with a per-package CONFIG_SITE file, and it can
includes dynamic run-time control options for any platform specific or
pkgsrc-controlled features....

That won't, unfortunately, work in 100% of cases (sometimes people write
tests that don't honour autoconf rules, sometimes even just as
unconrollable shell fragments in configure.in); nor will it avoid all
necessity to patch configure.in and re-generate configure scripts, but
it will go most of the way towards thwarting autconf's attempts to break
out of the pkgsrc mold.

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

Another very good approach would be to totally avoid running configure
in the first place (at least during pkgsrc driven builds).

I.e. the pkgsrc maintainer would run configure (and maybe automake) to
generate its output files on at least two different NetBSD platforms
(and perhaps all of them if it can be automated).  Then they would
re-code these generated files in such a was as to allow for dynamic
control (at build or run time) to account for any differences specific
to the individual platforms and to take into account the configurable
differences that pkgsrc allows for (such as $PREFIX, $X11PREFIX, etc.)

This would be very trivial for C-source headers (most commonly config.h,
where CPPFLAGS settings can suffice) and for any Makefiles (where the
existing MAKE_ENV is probably already sufficient).  It's a bit more
difficult for scripts and the like since you've either got to do another
substitution on them or have them read a semi-permanent config file on
every invocation at run-time (which might be a good thing for the
compiled programs too as it would allow for moving $PREFIX in binary
packages!).

All of these "generated" files would simply be copied into place by
patch from one big patch file, instead of running ./configure, and then
away you go with the build!  ;-)

The biggest drawback (other than the extra effort shouldered on the
pkgsrc maintainers) is the potential size of the additional patch file
each such pkg would require in pkgsrc....  :-(


The only other 100% solution I see is to try to re-activate a discussion
I tried to start amongst the autoconf community a year or so ago and to
try to help them build hooks into autoconf to integrate better with well
defined systems like pkgsrc.  That's certainly a longer term option no
matter what though....

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