Subject: Re: ltconfig [was Re: CVS commit: pkgsrc/graphics/imlib]
To: NetBSD Packages Technical Discussion List <tech-pkg@NetBSD.ORG>
From: Greg A. Woods <email@example.com>
Date: 08/14/2001 20:15:49
[ On Tuesday, August 14, 2001 at 16:18:06 (+0200), Dr. Rene Hexel wrote: ]
> Subject: Re: ltconfig [was Re: CVS commit: pkgsrc/graphics/imlib]
> This is why I (and several others) prefer using the original configure
> script instead of generating a new one from configure.in.
That's a VERY bad idea if you intend on modifying that script.....
Normally yes the original supplied configure script should be all that's
necessary to just build a package. However given the nature of software
it's not guaranteed that any random configure script released by any
random package author is bug free, especially in relation to the
constraints of the pkgsrc system.
Autoconf includes features to ensure that a new enough version is being
used to process the features in a given configure.in file. So far as I
know there are no known true backwards incompatability issues -- a newer
version of autoconf should always work with a configure.in file designed
for an older version (with the caveat that some warnings may be printed
about obsolete macros). However such incompatabilities are irrelevant
since the only time one would need to run autoconf is when a change to
configure.in is required, and any such incompatabilities and obsolescent
macros can be resolved/corrected at the same time.
If a new, working, configure script cannot be generated then something's
drastically broken with the package distribution.
I.e. in other words there should never be any fear of regenerating the
configure script before using it, at least not if any changes are
necessary to correct its operation either for NetBSD or for integration
with the pkgsrc system.
The only hard part is keeping devel/autoconf (or pkgtools/pkgautoconf)
up to date so that it's always as new as any package may require while
at the same time not forgetting to re-test other packages that patch
their configure.in files just in case some bug in autoconf itself causes
a backwards incompatability. However since autoconf isn't a quickly
moving target, this should not be a major problem.
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>