[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fw: MKS toolkit the 2nd
Re: Fw: MKS toolkit the 2nd
Sun, 08 Sep 2002 04:52:12 -0400
EMH/1.10.0 SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd)
> > 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,
> > 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
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.
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
% cvo /a/@cvo@
or doing a test against `cvo @address@hidden to see if the solaris kernel is at
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 .