Re: Fw: MKS toolkit the 2nd

[Harlan Stenn]

> > If making config.guess return useful/normal values is a goal, then
> > lets get rid of the cpu-vendor-linux-gnu braindamage
> 
> To do that you'll first need to fix the GNU coding standards, which
> specify the behavior here.  (It is a controversial area, so you'll
> have to make a good case.  :-)

Ah, like convincing folks the previous spec was just fine :-?

I almost apologize for that last sentence.  But it's been a few years since
the last time I brought up this topic, and both sides were polarized then,
too.

> > The primary reason for using config.guess is to talk about the total
> > environment
> 
> No, the primary reason for using config.guess is to talk about the
> canonical system name.  This is a relatively-narrow technical
> objective; it is a much smaller (and more achievable) goal than
> specifying the total environment.

True - I misspoke, and I should know better (thinking that otherwise we'll
head down the path of "what libc under this linux kernel and the following
packages", and then deal with Solaris kernel patch level, and 32 or 64-bit
Solaris, etc.

The canonical system name is just fine with me.

> Jeff Conrad's list of five significant things for Microsoft
> environments is OK as far as it goes, but that list is too small for
> actual environments and I don't see any realistic hope of shoehorning
> all the necessary information into the output of "config.guess", even
> assuming we could get the coding standards changed.  For most of those
> sorts of things it is better to use the Autoconf approach, where you
> test for the features that you need, rather than guessing the list of
> supported features from the canonical system name (or the "total
> environment" name, whatever that would be).  Autoconf and Automake
> support most (if not all) of the items that he mentions.

I have some wrapper code that calls config.guess and then returns a value
along the lines I mentioned before.

For example:

 linux> cvo
 CVO=i686-pc-redhat7.1
 CVO_CPU=i686
 CVO_KOSVER=2.4.9-34.bigco.2smp
 CVO_OS=redhat7.1
 CVO_OSNAME=redhat
 CVO_OSVER=7.1
 CVO_VENDOR=pc
 CVO_raw=i686-pc-linux-gnu
 linux>

and

 solaris> cvo
 CVO=sparc-sun-solaris2.8
 CVO_CPU=sparc
 CVO_KOSVER=Generic_108528-07
 CVO_OS=solaris2.8
 CVO_OSNAME=solaris
 CVO_OSVER=2.8
 CVO_VENDOR=sun
 CVO_raw=sparc-sun-solaris2.8
 solaris>

The "cvo" framework" supports shell, perl, tcl, and python at the moment.

I prefer a script (or a module) that has all the info needed and can return
the subset of the info that one wants at any given time.

The shell version of my cvo stuff does useful substitution if passed
arguments:

 % cvo /a/@cvo@
 /a/i686-pc-redhat7.1
 %

or doing a test against `cvo @address@hidden to see if the solaris kernel is at 
a
particular patch level.

I can see the benefit of having more info "available" to processes.

I don't see the benefit of trying to cram it all in to some enormous result
that comes back from config.guess .

H