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

[Eric Blake]

On 10/08/2012 06:46 AM, Paul Wise wrote:
> Hi all,
> 
> 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). We could
> patch every single package that contains config.guess and config.sub but
> that would be a lot of effort that doesn't scale. We could also patch
> our build tools but the problem would still exist for other distros.
> 
> I would like to get rid of this issue once and for all by making the
> update process for config.guess and config.sub once per machine or once
> per package instead of once per package.

Not to discourage you, but I still see a fundamental problem, where
things will just not scale for several more years (if ever).  Your
proposed patch will have no effect on packages that were shipped with a
configure script generated by autoconf 2.69 or earlier (that is, they
would only affect new packages built with the as-yet-unreleased autoconf
2.70).  Therefore, you STILL have to touch every single package that was
built with older toolchains to get them to take advantage of any new
self-upgrading code path built into a newer autoconf.

> 
> My initial approach in 2009 was to patch config.guess and config.sub to
> look for newer versions of themselves but the maintainer of these files
> wasn't happy with that approach.
> 
> I recently re-contacted him about this issue and was suggested to patch
> autoconf. The approach I have taken is to make autoconf-produced
> configure scripts use the package-local config.guess/config.sub by
> default and if that fails then find the newest config.guess/config.sub
> in a number of paths on the system and use it.

Is it safe enough to look at common system locations alone, or should we
also be attempting a network lookup for the latest canonical upstream
sources (of course, realizing that networking might not be available, so
we must not trigger fatal failure just because a machine is off the grid
at the time configure is run).

> I am not very familiar
> with autoconf internals, m4 or the intricacies of ancient shells, so I
> would very much appreciate a review of both the approach and my initial
> attempt at implementing this, please see the attached patch.

I haven't yet looked at the patch; it's non-trivial enough that it will
need copyright assignment to the FSF before it can even be considered.
But I'm first worried about the bigger implications of what you intend
to do about the fact that packages that were not built with autoconf
2.70 or later (assuming this patch makes it in) will still not benefit
from this patch.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature