[ On Thursday, May 30, 2002 at 19:30:59 (+0200), Alistair Crooks wrote: ]
> Subject: Re: BUILD_DEPENDS on autoconf
>
> If we could just moderate the tone of this discussion...

If it didn't keep re-appearing with such regularity an with an apparent
total lack of attention to past history....  :-)

> I've never understood the insistence that everything should be done
> by patching the configure.in input, and re-generating the configure
> scripts from that.

Pkgsrc must not assume it will be the sole source of patches to a
package.  Pkgsrc must not assume that it can patch the "configure"
script alone.  Local patches must be allowed to modify the
"configure.in" source file too, and thus allow for recreation of the
"configure" script et al from scratch.  If you're going to be patching
"configure.in" then you must not patch "configure" too, especially not
with hand-hacked patches.  You do not want to cart around huge patches
for "configure" scripts that might just be ignored anyway.

> To me, it introduces build-dependencies on autoconf,
> which are onerous in the extreme - nowadays, it means that perl needs
> to be installed on a system before you can build autoconf, and thus,
> to patch a package which needs modifications to its configure script,
> perl is a necessary pre-requisite.

Autoconf and Automake require perl, yes, but they're only BUILD
dependencies.  You don't need to have perl just to run a package that
was built using autoconf or automake.  C++ programs require a C++
compiler to be built.  I don't like C++ any more (or less) than I like
Perl, but yet I must install a C++ compiler (and associated goo) to be
able to build and use programs that other people have written in C++.
Similarly I must install perl in order to build and use some programs
that have used the GNU Auto* tools as part of their build process.  The
big difference with the GNU Auto* tools is that you don't always need
them.  Due to bootstrapping issues almost every package ships pre-built,
portable, configure scripts, etc.  These files only have to be fixed if
they're broken in some respect.  The only sane way to fix those files is
to edit their sources and rebuild them using the appropriate tools.

People building packages must expect to install all the necessary tools
required to do such builds.  Everyone else can use binary packages if
they feel the cost of installing the BUILD dependencies is too great for
them to bear.

Besides, if NetBSD pkgsrc maintainers are careful enough to make sure
all the hacks necessary to Auto* source files are accepted back by the
package authors and maintainers then pkgsrc patches can be removed and
the build dependencies on the GNU Auto* tools can be removed from the
updated pkgsrc modules.

(perhaps in an ideal world there Auto* source file patches would
collected in a file or files matching "patches/patch-configure-*" and
the pkgsrc infrastructure would automatically trigger the right default
dependencies and actions to required and use the GNU Auto* tools)


> Like I said, that's a very high price to pay, and I've yet to see
> any justification for that price.  Please enlighten me.

What costs do you see here?  I see very very little real cost.  Sure you
might not want to install perl on every NetBSD/vax or similarly slow and
ancient machine in the world, but why would you even build packages over
and over again on every such machine?  If you're going to be building
any significant number of packages on a slow VAX or such then you're
going to end up installing the likes of perl and GNU m4 et al anyway.
Beyond that the GNU auto* tools are just a simple set of scripts and
data files -- nothing complex or huge or in any way "very costly".

Besides it's almost impossible to build or use any significant portion
of pkgsrc without encountering a run-time dependency on perl.  Like it
or not, we have long ago been assimilated....  :-)

What machines do you regularly build packages on which don't already
have Perl installed?

-- 
								Greg A. Woods

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