From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9620 invoked from network); 14 Jan 2009 18:54:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) 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.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 14 Jan 2009 18:54:19 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 41356 invoked from network); 14 Jan 2009 18:54:13 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 Jan 2009 18:54:13 -0000 Received: (qmail 20569 invoked by alias); 14 Jan 2009 18:54:07 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26309 Received: (qmail 20551 invoked from network); 14 Jan 2009 18:54:06 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 14 Jan 2009 18:54:06 -0000 Received: from mail-ew0-f13.google.com (mail-ew0-f13.google.com [209.85.219.13]) by bifrost.dotsrc.org (Postfix) with ESMTP id 45B7680271F0 for ; Wed, 14 Jan 2009 19:54:02 +0100 (CET) Received: by ewy6 with SMTP id 6so808368ewy.21 for ; Wed, 14 Jan 2009 10:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=vqVRiFI4QWrPZVA3V0n7x3FSoyDPjHEXKY2JiBl23cY=; b=onIKxujDWSvT7FV8Rx68nMm858D+1fTjRFati31G2h420R7yTi73dUoKVw5Y+3smf5 zf/nTBD+2m+H3F1TXQemzpDVE+6sUNOaB6Ppg0sI6V+/IOORpUGlP11UI9UEgfTZ/6h2 cmST3xKjrR2T1K2pLqDxW3tg06ZexF3J/tfhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=dzXXL2eJceKKlqhg4OY2X5Sob59+oG2wEPXyQqZT5eq/OPTnMxhnAIvPrVkYNMGUfs kL3JsILsMnQ6DmF9PzmcW2hCreZ+pRy8YHmz4mVMyc0eIzguzsuLy3ft8Ef/TRYtoavQ wRHO74Q7G/C7u8MVAX5cj117D1K1e0hofv0nw= MIME-Version: 1.0 Received: by 10.210.119.16 with SMTP id r16mr487559ebc.185.1231959242320; Wed, 14 Jan 2009 10:54:02 -0800 (PST) In-Reply-To: <090114085737.ZM18662@torch.brasslantern.com> References: <2d460de70901090301h6b309a7cm19c5ebfec989ff2c@mail.gmail.com> <2d460de70901140533icf13f94yc7f63f974b236f45@mail.gmail.com> <090114085737.ZM18662@torch.brasslantern.com> Date: Wed, 14 Jan 2009 19:54:02 +0100 Message-ID: <237967ef0901141054y35a4fafdpade3134bc49f69aa@mail.gmail.com> Subject: Re: Getting the CVS revision of Zsh From: Mikael Magnusson To: zsh-workers@sunsite.dk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/8865/Wed Jan 14 18:37:08 2009 on bifrost X-Virus-Status: Clean 2009/1/14 Bart Schaefer : > On Jan 14, 2:33pm, Richard Hartmann wrote: > } > } My suggestion would be to introduce a new variable called > } $ZSH_RELEASE which is only filled if the source zsh was > } compiled from is tagged as a release. > } > } Thoughts? > > My thought is that all of this, including ZSH_PATCHLEVEL, should > never have been bothered with in the first place. > > Either you're compiling zsh from source yourself, in which case you > should know what you're compiling; or you're using a package that was > installed by somebody else, in which case it's between you and that > somebody if you're having bleeding-edge non-releases forced on you. > > If you're a packager like Debian or RedHat who occasionally ports > individual patches backwards or sideways or makes your own stability > patches, anything in these variables is going to be either wrong and > misleading to the end user or fabricated and meaningless to the zsh > developers upstream. > > I was holding my tongue on ZSH_PATCHLEVEL despite my annoyance that > it uses the RCS $Revision: tag -- I mirror the zsh sources into my > own local repository, which means that tag gets rewritten whenever > I do a check-in, so my local build will rarely if ever match the > "real thing", hence it's useless cruft to me -- and I suppose it's > up to PWS if he wants to jump through the hoops to make something > like this appear to work, but I'm completely unconvinced by the > argument that they're in some way beneficial. FWIW, I use a git import which doesn't do any keyword expansion, so the define is empty in my case, which obviously breaks the build. I don't know if you want to a) not care b) add some #ifdef to set it to "unknown" or such or c) add some shell code for git to set it. If b or c I can construct a patch. -- Mikael Magnusson