Re: [RFC] pass #2 at getting rid of the config.guess/sub problem when bootstrapping new ports/systems

[Adrian Bunk]

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