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

[Mike Frysinger]

On Wednesday 22 May 2013 12:27:38 Eric Blake wrote:
> On 05/22/2013 10:22 AM, Mike Frysinger wrote:
> >> I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB
> >> environment variable, rather than baking in a PATH search.  This topic
> >> has come up in the past, where I made the same request back then.
> > 
> > this might be sufficient for distro packagers (once they're "in the know"
> > that they have to export these two), but that doesn't help people who
> > download arbitrary packages and run `./configure` themselves.
> > 
> > what if the autoconf macros grew a new option/macro so that in the very
> > uncommon case that someone has written their own, they could explicitly
> > declare so ?
> > 
> >     AC_CANONICAL_CUSTOM
> > 
> > this would disable the custom search path and only respect the env vars
> 
> I still don't see why you are overengineering things.  Make the env-var
> precious - then it will show up in ./configure --help output, and be
> preserved so that ./config.status --config will show you what it was set
> to at the time.  If the only way to get the override is via an env-var,
> then there is no need for the complexity of either a baked-in path
> search nor a means of letting SOME packages disable the complexity of a
> baked-in path search.  If you can argue that SOME packages will want to
> disable the complexity, then I can argue that we should make the default
> of disabled complexity be everywhere.

i don't have a problem throwing out support for custom config.{guess,sub} 
files.  
as noted elsewhere in this thread, i believe that to be an obsolete art.

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

signature.asc
Description: This is a digitally signed message part.