[ On Wednesday, May 12, 1999 at 09:41:46 (-0400), Todd Vierling wrote: ]
> Subject: Re: qpopper needs gdbm? 
>
> However, it's unwritten policy to patch the configure script if you need to
> `if-bracket' something.  In other circumstances, we patch both configure.in
> and configure (in that order), where the configure patch is the changed
> portion of the regenerated script.  We SHOULD NOT add dependencies on
> autoconf, as that adds even more hidden dependencies (...not everyone wants
> perl just to build a couple small pkgs).

Say what?!?!?!?  First off plain old autoconf doesn't require perl -- it
requires GNU M4 (though I've been planning to see what can be done about
making it work with NetBSD's M4, whether that means fixing "our" m4, or
adjusting autoconf to be a bit more lenient or both).  It's automake
that requires perl....

Secondly generating the "configure" patch and passing it around, instead
of simply regenerating the entire script from a patched "configure.in",
is just bad juju.  It's like shipping source patches along with object
and binary patches just so that you don't have to recompile even though
you can.  Even worse the patch to configure after regenerating it is
often far more massive than a quick hack inside of it would be, and
definitely more massive than the equivalent "configure.in" patch (which
isn't meant to condone quick "configure" hacks, but rather to show that
patching generated files is usually a very inefficient way to do
things).

Thirdly I thought "we" had already agreed that patching configure.in and
depending on autoconf was "The Right Way" to do things in pkgsrc.  There
are already a number of packages that work this way, including the ones
I've submitted patches for that include this change.

Finally the *right* way to fix this AC_CHECK_LIB() issue is to fix
autoconf such that it can be told much more reliably what it should or
should not do with "optional" requirements such as add-on libraries.
I've always thought it was wrong for it to "assume" that if you *happen*
to have libreadline (for example) then *obviously* you want everything
you build to use libreadline if it can.  Clearly when binary packages
are involved dependencies on run-time libraries are critically
important.  Discussion in the autoconf mailing list has already been
started on this issue.

-- 
							Greg A. Woods

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