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 eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
