Harlan Stenn wrote:
> > > I think you are missing my point.
> > > The information I am talking about is used for *runtime* decisions - very
> > > likely in a script that is in a shared directory used by many different
> > > architectures.
If for use at runtime then config.guess is very poorly suit
Harlan Stenn wrote:
> > Well, you can create and maintain a 'config.linuxdistro' on your own...
>
> Yes, and then code:
>
> ...
> cvo=`config.guess`
> case $cvo in
> *-*-linux-gnu)
> cvo=`config.linuxdistro`
> ;;
> esac
> ...
Yes. This is how it's meant.
> everywhere one would othe
> This is too simple. It increases the temptation to use the distro's name,
> instead of writing an autoconf test. I've already explained that this is
> undesirable because it limits the freedom to fork a new distribution.
You keep insisting that the output only be used for autoconf.
I am talking
> > It is way to late to even think about changing things now.
It's never too late to improve software.
The amount of software that will be created from here on can be reasonably
expected to be MUCH greater than what has been written so far.
The change to, for example:
i686-DistroRev-linux-gnu
Bob Friesenhahn wrote:
> One handy use when building for multiple architectures is to use
> config.guess to supply part of the build directory name so that it is
> very easy to manage heterogeneous builds within one file system.
Agreed. That's a use of the distribution name and version that won't
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
On Wed, 14 Jan 2004, Scott James Remnant wrote:
> On Tue, 2004-01-13 at 21:25, Harlan Stenn wrote:
>
> > I think you are missing my point.
> >
> > The information I am talking about is used for *runtime* decisions - very
> > likely in a script that is in a shared directory used by many different
>
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
> > I think you are missing my point.
> >=20
> > The information I am talking about is used for *runtime* decisions - very
> > likely in a script that is in a shared directory used by many different
> > architectures.
> Oh, well, config.guess isn't designed for that -- it's for compile time
> dec
On Tue, 2004-01-13 at 21:25, Harlan Stenn wrote:
> I think you are missing my point.
>
> The information I am talking about is used for *runtime* decisions - very
> likely in a script that is in a shared directory used by many different
> architectures.
>
Oh, well, config.guess isn't designed fo
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
I think you are missing my point.
The information I am talking about is used for *runtime* decisions - very
likely in a script that is in a shared directory used by many different
architectures.
While it may be one possible implementation to run a configure script at
startup time, it quickly beco
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:
> > The differences between ALL of the various linux-gnu implementations are
> > so slight that they are far more suited to feature tests than something
> > like this.
>
> Are you really serious? ...
>
> - RC files?
> - packaging mechanism?
> - automount filesystem selection bas
> 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
> > [1] 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 a=
> nd
> > would prefer to see something like:
> >
> > i686-pc-redhat7.3
> >
> > instead, just like the original documenta
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 Wed, 2004-01-07 at 05:51, Harlan Stenn wrote:
> [1] 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, ju
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
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
-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
I almost wonder if it would make sense to look at something like "mtree" to
fix up the permissions of an installed package.
It's a nasty problem.
H
Howdy Alexandre,
> Happy new year.
Thanks, and same to you.
> >>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
>
> Harlan> This change:
> Harlan> - Makefiles will prefer `mkdir -p' over mkinstalldirs if it is
> Harlan> available. This selection is achieved through the Makefile
> H
[ The reason I initially included Billy and Bruno in the Cc is
that as Billy was the first to raise these issues he may want to
further comment on, and whatever we do with mkdir/mkinstalldir
may have some repercussions on Gettext (and vice-versa). Please
keep them in the loop. ]
>>> "Russ" == Rus
Andrew Suffield <[EMAIL PROTECTED]> writes:
> On Sat, Jan 03, 2004 at 04:25:47PM +0100, Alexandre Duret-Lutz wrote:
>> - is it normal to honor umask when creating directories and not
>>when installing files?
> I'd say it was normal to honour umask at all times. People who ask for
> applicat
On Sat, Jan 03, 2004 at 04:25:47PM +0100, Alexandre Duret-Lutz wrote:
> - is it normal to honor umask when creating directories and not
>when installing files?
I'd say it was normal to honour umask at all times. People who ask for
applications to ignore umask because they have a silly umask
Hi Harlan,
Happy new year.
>>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Harlan> This change:
Harlan> - Makefiles will prefer `mkdir -p' over mkinstalldirs if it is
Harlan> available. This selection is achieved through the Makefile
Harlan> variable $(mkdir_p) that is set by AM_I
This change:
- Makefiles will prefer `mkdir -p' over mkinstalldirs if it is
available. This selection is achieved through the Makefile
variable $(mkdir_p) that is set by AM_INIT_AUTOMAKE to either
`mkdir -m 0755 -p --', `$(mkinstalldirs) -m 0755', or
`$(install_sh) -m 0755 -d'.
34 matches
Mail list logo
