[ On Friday, May 31, 2002 at 10:44:16 (-0500), Richard Rauch wrote: ]
> Subject: Re: BUILD_DEPENDS on autoconf
>

Thank you for distilling the points I've been trying to make into a
more palatable form!  ;-)


> (Providing patches against both
> configure.in and configure may be workable.

It can work, but it can also lead to "surprising" failures, especially
if more local patches change configure.in again.  It is far less than
ideal and nowhere near perfect.

To be really "workable" though this methodology _MUST_ be accompanied by
a configuration optoin which allows the user to choose whether to
re-compile the GNU Auto* inputs or not.  This probably means inventing
some new naming conventions for patch files so that pkgsrc can avoid
applying some of them when this switch is set to require running
autoreconf et al.


>  Greg seems to say that that
> would involve massive diff's for the configure patches, though, and
> there's the problem of ensuring that the two files are in synch...)

That situation is improving with the modern Autoconf.  A recent feature
that causes configure to reprocess itself allows the internal debugging
code to avoid having to have hard-coded line numbers.  For example the
diff for security/sudo's change is not very much larger than the patch
for the configure.in itself.  Of course the hacks for that particular
configure.in are not much better than its current implementation.  I
don't have any other good examples to compare with at the moment, and I
wouldn't want to assume this situation will remain as good as it might
appear at the moment.

What I _REALLY_ want to avoid are the hand-made hacks to the "configure"
scripts and "Makefile.in" files that currently still exist in pkgsrc.
Those hacks are _extremely_ frustrating to deal with.

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