> > 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 @kosver@` 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
