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

[Eric Blake]

On 10/12/2012 05:46 PM, Roger Leigh wrote:
>> 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.

No, you don't.  If CONFIG_GUESS is a precious variable, then you can set
it in your environment before running configure on any of those 30k
packages, instead of having to add it to 30k individual command lines.

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

Because it's too hard-coded, compared to the flexibility of an env-var.
 Why does 'make' honor $CC instead of probing a hard-coded list?  For
the same reason.

>  Are there any
> significant downsides to doing so?

Yes, complexity.  Since an env-var already solves the solution, we don't
need the added complexity of also probing for fixed locations.

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

Indeed, and that's why adding support for $CONFIG_GUESS sounds like a
good idea.

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

signature.asc
Description: OpenPGP digital signature