[ On Wednesday, May 12, 1999 at 15:25:50 (-0400), Todd Vierling wrote: ]
> Subject: Re: qpopper needs gdbm? 
>
> : Say what?!?!?!?  First off plain old autoconf doesn't require perl -- it
> : requires GNU M4
> 
> `Try again.'  The autoscan script is written in Perl, and as such, the
> autoconf pkg depends on Perl.  (USE_PERL5)

Yes, I know about that, but autoconf doesn't actually *require* perl,
and certainly not for use within pkgsrc.  Autoscan is an optional script
and the autoconf build will happily skip building autoscan if perl isn't
available on the build machine.  Autoscan (and thus perl) is most
definitely not needed to rebuild an existing configure script.

Of course building autoconf without USE_PERL is a perfect example of a
run-time dependency unrelated to shared libraries that will result if
the "binary" package is built on a machine with perl and installed on
one without.....  ;-)  [though it is much less aggrevating and much more
obvious to the average user than an unsatisfied shared library dependency]

> It's also a lot faster to build, and often (in the case of quick hacks)
> would otherwise require major revision of the configure.in.
> 
> Regenerating configure, diffing it against the shipped configure, and
> stripping out the changes that are only #line directives, provides a faster
> build path for the pkg on systems that don't have all of {autoconf,gm4,perl}
> installed.

I haven't yet encountered a single case of a package where anything more
than extremely minor changes are required in the configure.in....  I
won't claim to be 100% familiar with all of the pkgsrc tree, but I have
encountered many of the more complex packages which do have hidden
dependencies.

It's also a *lot* more complex job for the developer, and though it
could possibly be automated somewhat, at least to some people's liking,
it's still a messy and unnecessary extra step.

And it's not a "lot" faster either.  I can tell you from first-hand
experience that autoconf is quite fast at running, even on slower
machines like small old sun3s and such -- for anyone already accustomed
to doing builds on such machines it'll be simply par for the course.
Automake, particularly with perl5 instead of perl4, is a bit slower,
especially for big projects, but still running it would beat the heck
out of trying to maintain patches for all the Makefile.in's.  Besides,
you only have to download and install the build tools once, and only on
the build machine, and it can all happen automagically, and if you do
any amount of pkgsrc maintenance you'll need them anyway....

There's also the issue of version skew.  If you force developers (well,
actually 3rd-party developers such as myself simply won't be forced) to
maintain "configure" patches in sync then you *will* end up with a
situation where the pkgsrc version of autoconf cannot be used to
generate those patches because even though a newer version of autoconf
will work just fine (or maybe even better), the resulting diff to
configure can be much larger than configure!

I'm reasonably certain that the days of ancient and incompatible
configure.in files are gone, especially for anything likely to be of
significant enough interest that it'll appear in NetBSDs pkgsrc.
I.e. it is unlikely that "upgrading" to using the pkgsrc autoconf will
require major changes to a given package's configure.in.

One other minor issue that I've not mentioned yet has to do with the
applicability of a "configure" script patch to other platforms on which
pkgsrc might be used.  We've already got a head start on using pkgsrc on
Solaris, and though many of the hidden shared library dependencies I've
seen are for the moment all encompassed by pkgsrc, it's not hard to
imagine a scenario where a hand-made patch to the "configure" script
will cause it to fail on another system.  This is a relatively minor
issue, especially for me, but it's an excellent indicator of which
approach is more correct.

> : 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.
> 
> Tell the FSF people, not us.

Like I said, at least twice already, I've started to open that door (and
it's not FSF that matters here -- it's the autoconf developers, and I do
participate on the autconf mailing list).

However if a larger number of packaging system maintainers would get
together and help work out some better requirements for configuration
systems like autoconf the necessary fixes would not only be quicker in
coming, but they'd also be much more likely to meet the actual
requirements, instead of just those perceived by the autoconf developers
third-hand.

There's a very good chance that fixing this "right" will require the
co-operation of GNU Automake, and possibly libtool too.  The more heads
there are working on the root of this problem (instead of patching
around it six ways to Sunday), the better.

The most elegant solution from the Auto* point of view may be to
integrate the packaging system, but that is likely to be counter to the
needs of a more generic system like the pkgsrc tree (i.e. any system
that has to deal with non-auto*'ed sources).  If a happy medium could be
found then everyone might come out a winner....

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