From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6116 invoked from network); 1 Jun 2008 17:52:57 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 1 Jun 2008 17:52:57 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 14227 invoked from network); 1 Jun 2008 17:52:53 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 1 Jun 2008 17:52:53 -0000 Received: (qmail 4133 invoked by alias); 1 Jun 2008 17:52:51 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25126 Received: (qmail 4117 invoked from network); 1 Jun 2008 17:52:50 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 1 Jun 2008 17:52:50 -0000 Received: from cork.scru.org (cork.scru.org [209.20.67.2]) by bifrost.dotsrc.org (Postfix) with ESMTP id 2E3CB80589A4 for ; Sun, 1 Jun 2008 19:52:46 +0200 (CEST) Received: by cork.scru.org (Postfix, from userid 1000) id 3F5C510417F; Sun, 1 Jun 2008 17:52:43 +0000 (UTC) Date: Sun, 1 Jun 2008 17:52:43 +0000 From: Clint Adams To: Bart Schaefer Cc: zsh-workers@sunsite.dk Subject: Re: PATCH: LFS Message-ID: <20080601175243.GA7266@scru.org> Mail-Followup-To: Bart Schaefer , zsh-workers@sunsite.dk References: <20080531182709.GA14185@scowler.net> <20080601172035.5bb8ad41@pws-pc> <20080601163611.GA5930@scru.org> <080601101954.ZM11463@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <080601101954.ZM11463@torch.brasslantern.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Virus-Scanned: ClamAV 0.91.2/7316/Sun Jun 1 18:10:43 2008 on bifrost X-Virus-Status: Clean On Sun, Jun 01, 2008 at 10:19:54AM -0700, Bart Schaefer wrote: > I know I'm nit-picking here, but I think it would be better to reformat > more of the paragraphs to avoid very long/very short lines, rather than > concentrate on producing the smallest possible diff. > > (Why was it even necessary to change "lfs" to "largefile" in the first > place? Force people to notice by deliberately breaking existing their > existing config.status?) What happened was that I discovered the hard way that the previous largefile detection support would abort if CPPFLAGS was set but null. Rather than protecting against this case by changing a + to a :+, it struck me as much more robust to switch to autoconf's AC_SYS_LARGEFILE; that way it will do the right thing if CPPFLAGS is set to the null string, and even if it is set to arbitrary flags, and theoretically do so on more platforms than previously. We could hack --enable-lfs back in as some kind of alias to --enable-largefile, but I suspect that it would be flimsy and dependent on autoconf internals. Another option is to make zsh_LARGE_FILE_SUPPORT behave exactly as autoconf's AC_SYS_LARGEFILE except for s/largefile/lfs/ , but that would deprive us of automatically receiving the benefits of any upstream AC_SYS_LARGEFILE fixes or enhancements. Better ideas? Index: INSTALL =================================================================== RCS file: /cvsroot/zsh/zsh/INSTALL,v retrieving revision 1.35 diff -u -r1.35 INSTALL --- INSTALL 1 Jun 2008 16:39:09 -0000 1.35 +++ INSTALL 1 Jun 2008 17:40:07 -0000 @@ -469,15 +469,16 @@ ------------------------------------ Some 32-bit systems allow special compilation modes to get around the 2GB -file size barrier. This is enabled by default; use --disable-largefile to turn -it off. Not all systems recognize the test used by zsh (via the getconf -command), so flags may need to be set by hand. On HP-UX 10.20, zsh has -been successfully compiled with large file support by configuring with +file size barrier. This is enabled by default; use --disable-largefile +to turn it off. Not all systems recognize the test used by zsh (via the +getconf command), so flags may need to be set by hand. On HP-UX 10.20, +zsh has been successfully compiled with large file support by configuring +with CC="cc -Ae" CPPFLAGS="-D_LARGEFILE_SOURCE -D_FILE64" configure \ --enable-largefile ... -Furthermore, use of --enable-largefile will also enable 64-bit arithmetic for -shell parameters, and anywhere they are used such as in mathematical +Furthermore, use of --enable-largefile will also enable 64-bit arithmetic +for shell parameters, and anywhere they are used such as in mathematical formulae. This depends only on the shell finding a suitable 64-bit integer type; it does not require that support for large files is actually enabled. Hence --enable-largefile is useful on many 32-bit systems Index: Src/zsh.h =================================================================== RCS file: /cvsroot/zsh/zsh/Src/zsh.h,v retrieving revision 1.135 diff -u -r1.135 zsh.h --- Src/zsh.h 1 Jun 2008 16:39:10 -0000 1.135 +++ Src/zsh.h 1 Jun 2008 17:40:21 -0000 @@ -34,9 +34,8 @@ * Our longest integer type: will be a 64 bit either if long already is, * or if we found some alternative such as long long. * Currently we only define this to be longer than a long if - * --enable-largefile - * was given. That enables internal use of 64-bit types even if - * no actual large file support is present. + * --enable-largefile * was given. That enables internal use of 64-bit + * types even if no actual large file support is present. */ #ifdef ZSH_64_BIT_TYPE typedef ZSH_64_BIT_TYPE zlong;