[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: |
Mike Frysinger |
Subject: |
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems |
Date: |
Thu, 23 May 2013 12:31:38 -0400 |
User-agent: |
KMail/1.13.7 (Linux/3.8.3; KDE/4.6.5; x86_64; ; ) |
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.
- Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems, (continued)
- Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems, Eric Blake, 2013/05/20
- Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems, Paul Wise, 2013/05/20
- Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems, Eric Blake, 2013/05/20
- Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems, Paul Smith, 2013/05/20
- Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems, Wookey, 2013/05/20
- Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems, Eric Blake, 2013/05/20
- Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems, Mike Frysinger, 2013/05/22
- Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems, Eric Blake, 2013/05/22
- Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems, Mike Frysinger, 2013/05/22
- Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems, Eric Blake, 2013/05/23
- Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems,
Mike Frysinger <=
- Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems, Mike Frysinger, 2013/05/22