From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8625 invoked from network); 26 Mar 2000 18:59:26 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 26 Mar 2000 18:59:26 -0000 Received: (qmail 20756 invoked by alias); 26 Mar 2000 18:59:17 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10255 Received: (qmail 20734 invoked from network); 26 Mar 2000 18:59:15 -0000 Date: Sun, 26 Mar 2000 13:58:44 -0500 From: Clint Adams To: Zefram Cc: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: 3.1.6-dev-20: runtime determination of MACHTYPE Message-ID: <20000326135844.A15544@scowler.net> References: <20000325104018.A3765@dman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from zefram@fysh.org on Sun, Mar 26, 2000 at 02:13:05PM +0100 > It's not that easy. Look at config.guess: $MACHTYPE is not always > the same as `uname -m`. Leave $MACHTYPE being compiled in as it was. > If you want access to the runtime uname strings without forking off a > uname process, invent a new special parameter. The behavior of config.guess is a bit inconsistent, and this description is a little vague. MACHTYPE The machine type (microprocessor class or machine model), as determined at compile time. What was the original purpose of the parameter? Seems to me that `uname -m`, `uname -p`, and the output of arch(1) are often a stretch from what one might infer from their descriptions, anyway, not to mention inconsistent, but if MACHTYPE is set to sparc without regard for whether I'm on a SuperSPARC or an UltraSPARC, whether I'm running Solaris or Linux, then why differentiate between types of Alpha or x86? Especially if the same chip will be i686 under Linux and i386 under FreeBSD? The problem's scope is really beyond zsh, but if a parameter is compiled in, it should be a generic "CPU architecture" type (e.g. sparc, ix86/i386, alpha, m68k, &c.), and if it's defined at runtime, it should be more specific. So I'm fine with adding a new parameter and keeping MACHTYPE static, but in that case I think that MACHTYPE should become more generic. Anyone disagree?