On Sat, Oct 13, 2012 at 12:46:11AM +0100, Roger Leigh wrote:
> On Mon, Oct 08, 2012 at 10:03:09PM -0600, Eric Blake wrote:
> > On 10/08/2012 09:27 PM, Paul Wise wrote:
> > > On Mon, 2012-10-08 at 20:46 +0800, Paul Wise wrote:
> > >
> > >> So, Debian is in the process of bringing up our upcoming arm64 port.
> > >> Unfortunately we are also coming across lots of packages with rather
> > >> outdated config.guess and config.sub files (see links below).
> > >
> > > I've taken on board advice received during this thread and elsewhere and
> > > updated the patch to always use the latest config.guess and config.sub
> > > files. I've also tested the result on one of the things I'm upstream for
> > > and it works to my satisfaction. The only downside is that there is a
> > > code block that occurs twice in each generated configure script, but I'm
> > > not sure how to avoid that, any pointers? Please see the attached patch.
> >
> > I still prefer the idea of being able to set an environment variable,
> > $CONFIG_GUESS, rather than going hunting ourselves. Then, porting to a
> > new config.guess script is a matter of calling:
> >
> > ./configure CONFIG_GUESS=/path/to/new/version
> >
> > rather than hoping that a hard-coded hunt will find the new config.guess
> > appropriate for the system wanting the upgrade path.
>
> This does not solve the problem. You still then have to update
> up to 30K packages to run configure with this new argument. While
> using an env var is fine to override the default behaviour, this is
> really somewhere where having it behave sensibly by default without
> any special action is required. Is defaulting to checking in
> standard places like $datadir/misc so difficult? Are there any
> significant downsides to doing so? Long-term, having configure
> pick up a current config.guess/sub (and libtool) is something of
> enormous benefit, because the current approach of embedding them
> causes more problems than it solves.
The sensible action is to use the known-working versions that are
shipped by default.
Picking up newer, or older, or oddly patched, versions of such tools
that happen to be installed on the system has a high probability of
causing breakages.
As an example, there were many packages that needed small updates when
switching from libtool 1.5 to libtool 2.2.
Building packages on a new platform is a special case, and should be
treated as such without introducing new problems in the default case.
> Regards,
> Roger
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
