autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
Date: Thu, 23 May 2013 08:31:26 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

On 05/22/2013 11:43 AM, Mike Frysinger wrote:
> my point for keeping the automatic search behavior is so that people don't 
> have to pour through --help output and set yet-more esoteric variables so 
> things "just work".  you're of course right that by having two variables 
> results in dirt simple code on the implementation side.  but the end user 
> experience is terrible.  however, adding a patch search, while is "more" 
> code, 
> is not complicated, and both the end user and distros win.
> 
> the code could even be made simpler if we throw out the --time-stamp check 
> and 
> accept things based purely on their name.  simply leverage AC_PATH_PROG.

Maybe you have a point there.  Basically, I'd like $CONFIG_GUESS to
behave like $CC, and maybe searching the user's PATH is worth trying
first, falling back to our in-tree version if a path search turns up
nothing, and where the env-var always takes precedence.  I still don't
think we need to hard-code any additions to the user's path.  After all,
the ONLY time that using a newer config.guess will help you is when
porting to a new machine type that was not present in an older
config.guess; but if you argue that the first thing a distro does when
preparing a port to a new machine triple is to install an updated
/usr/bin/config.guess, then that will be sufficient to let all the other
new enough packages automatically find the right triple.  Even if
/usr/bin/config.guess is older than the one bundled with an (even newer)
package, it is still new enough to support the target triple on which
you are compiling that package.  So favoring a PATH lookup over the
in-tree version should always work, and falling back to the in-tree
version instead of outright failing should work for all situations where
config.guess is not installed on the user's PATH.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]