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

[Mike Frysinger]

On Thursday 23 May 2013 10:31:26 Eric Blake wrote:
> 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.

i don't think anyone installs these things into $PATH today.  we put them into 
/usr/share/ somewhere.  the idea with the custom path search was so that you 
didn't need to be running a good distro for this stuff to work ... it would 
work with any system that follows default libtool/automake install 
conventions.

i misread the patch and what it was doing with --timestamp.  the point was to 
make sure it didn't inadvertently select an older version.  so i guess i'm in 
favor of the current (more complicated) version :/.

the automake-1.12+ has a --print-libdir option.  what if we use that rather 
than hardcoding the automake paths ?

if we're all in agreement with the $CONFIG_SUB / $CONFIG_GUESS starting point, 
maybe we merge that now and continue debating the extended points ?
-mike

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