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
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
