On Tue, 2004-01-13 at 18:18, Bob Friesenhahn wrote:
> On Tue, 13 Jan 2004, Bob Proulx wrote:
> >
> > > If the releases are all that similar, why not use:
> > >
> > > i686-GnuLinux-*
> > >
> > > as your test, and provide the "popular" distributions in the 3rd field?
> > >
> > > The "magic" command
I bet you have never tried to deploy this in the real world in an
environment with a useful number of heterogeneous OS installations running
at different OS rev levels.
In my experience this simply doesn't scale. Especially if it gets used in
somebody's shell RC files.
Your approach still "speci
If there was a version number in the Vendor field I'd be lots happier.
In the RH distros I've seen (and the config.guess output on those boxes) I
have still only seen "pc" for the Vendor field.
H
--
> On Tue, 2004-01-13 at 13:43, Bruno Haible wrote:
> > Harlan Stenn wrote:
> >
> > > If the relea
On Tue, 2004-01-13 at 13:43, Bruno Haible wrote:
> Harlan Stenn wrote:
>
> > If the releases are all that similar, why not use:
> >
> > i686-GnuLinux-*
> >
> > as your test, and provide the "popular" distributions in the 3rd field?
>
> This is a little more reasonable,
How would that be basical
On Tue, 13 Jan 2004, Bob Proulx wrote:
>
> > If the releases are all that similar, why not use:
> >
> > i686-GnuLinux-*
> >
> > as your test, and provide the "popular" distributions in the 3rd field?
> >
> > The "magic" command has a large database of selections on it; using this
> > sort of mecha
Harlan Stenn wrote:
> The good news and bad news is that your position is a POLICY decision.
>
> I am talking about a MECHANISM tool.
Agreed. But it is not a mechanism of automake. Nor should the
autotools support it since it embodies a diametrically opposed
philosophy from the one the autotool
Harlan Stenn wrote:
> If the releases are all that similar, why not use:
>
> i686-GnuLinux-*
>
> as your test, and provide the "popular" distributions in the 3rd field?
This is a little more reasonable, since it allows to check for Linux with
a single test. But the fundamental problem remains: y
> Harlan Stenn wrote (meaning "Linux distribution" when he writes "OS"):
> > help tool maintainers make choices
> > about how things that are hard to find out otherwise (like OS-based
> > choices).
> > ...
> > everybody who wants to make OS-level decisions has to code their own tests
> > to figure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Corsepius wrote:
| I don't know how libtool applies config.guess and if/how my
| problems with libtool are connected to config.guess'ing.
Here is a short (but not atypical) example of the sort of thing libtool needs
config.guess for:
case $host_os
On Thu, Jan 08, 2004 at 10:53:58AM +, Gary V. Vaughan wrote:
> Ralf Corsepius wrote:
> | Sorry for having to say this, but IMO, configure scripts relying on
> | config.guess'ed values are "badly designed and fundamentally flawed".
>
> It's a pity you think that. I always found libtool to be r
On Thu, 8 Jan 2004, Gary V.Vaughan wrote:
>
> > Another problematic case is ensuring "correctness" of guess-derived
> > results. Without additional checks, you can't guarantee anything.
> > Eg. wrt. host_os, you can't guess on the object format or if an OS
> > honors LD_LIBRARY_PATH/LD_RUN_PATH or
On Thu, 2004-01-08 at 11:53, Gary V. Vaughan wrote:
> Ralf Corsepius wrote:
> | Sorry for having to say this, but IMO, configure scripts relying on
> | config.guess'ed values are "badly designed and fundamentally flawed".
>
> It's a pity you think that. I always found libtool to be rather useful
On Thursday, January 8, 2004, at 04:32 pm, Ralf Corsepius wrote:
Wrt. your example: You are supporting aix3*. Now IBM renames AIX to
something else or changes some fundamental characteristics of their OS
without changing the $host_os.
All you can do is to extend, extend and extend your "case".
Agr
Harlan Stenn wrote (meaning "Linux distribution" when he writes "OS"):
> help tool maintainers make choices
> about how things that are hard to find out otherwise (like OS-based
> choices).
> ...
> everybody who wants to make OS-level decisions has to code their own tests
> to figure out the OS nam
On Thu, 2004-01-08 at 16:42, Gary V. Vaughan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ralf Corsepius wrote:
> | I don't know how libtool applies config.guess and if/how my
> | problems with libtool are connected to config.guess'ing.
>
> Here is a short (but not atypical) examp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Corsepius wrote:
| Sorry for having to say this, but IMO, configure scripts relying on
| config.guess'ed values are "badly designed and fundamentally flawed".
It's a pity you think that. I always found libtool to be rather useful.
Cheers,
- --
Ga
On Wed, 2004-01-07 at 22:51, Harlan Stenn wrote:
> > A configure script that has to check for 125 brand names, only for Linux,
> > is not only unmaintainable, it also limits the freedom to fork a new
> > distribution.
>
> So for this reason people who write scripts (autoconf or otherwise) who can
(I am in a slightly crabby mood. I apologize. Bikeshed begins.)
> Harlan Stenn wrote in a footnote:
> > There are people who think a config.guess output that says:
> >
> > i686-pc-linux-gnu
> >
> > is "normal", while some of us feel that is a particularly useless value and
> > would prefer to s
Harlan Stenn wrote in a footnote:
> There are people who think a config.guess output that says:
>
> i686-pc-linux-gnu
>
> is "normal", while some of us feel that is a particularly useless value and
> would prefer to see something like:
>
> i686-pc-redhat7.3
>
> instead, just like the original doc
19 matches
Mail list logo
