From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26995 invoked by alias); 17 Nov 2013 20:20:40 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32000 Received: (qmail 3128 invoked from network); 17 Nov 2013 20:20:35 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=t3QCcpTp3zbx2lGgIPgwOwXWu2gR2emlkmz73A7O76k=; b=jyUbE92tgaNSe7QclON2Lbg5Ym/1WGJY3pbkNMcO1dojnO+z/TLPP54hJd8dphmehD gl4AJSSOpXD4WZwgd5n27h1iJO402jF/icBtyedfV54beMJVou7WTFiHeanpUGwDBj43 t+AutwTnjr2cwLn/HNvijL5PIpWTig3ZjRSkB4LBnUGc0G5AGaE6Aofw2BEx0F4TghAN ZPzmqN7wrF5RDYhJt0bnKwlj21mVZXKHsjllKjmULhq6BziLi+fx3PXMYhSFYRdSeDNy 4IAA8GcsDfSnA5UEPtMvJyFb1f8hAdxrX/NfLAOIkpDQWrBcryfhSYIeKpAzEk4O6VtE 4mTA== X-Gm-Message-State: ALoCoQmiBd9tx5ejM+RZJ94ZrnZT+mvgalc5+zXv39sEje70uOVbI1xNw8bVF8IrmrgaNNbCzQfU X-Received: by 10.180.8.98 with SMTP id q2mr14359037wia.26.1384719241979; Sun, 17 Nov 2013 12:14:01 -0800 (PST) X-ProxyUser-IP: 86.6.157.246 Date: Sun, 17 Nov 2013 20:13:59 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: modify functions hierarchy (was: Install run-help and *.zwc files system wide in build system) Message-ID: <20131117201359.1613ec4c@pws-pc.ntlworld.com> In-Reply-To: <131117103047.ZM30518@torch.brasslantern.com> References: <20131110181333.7682d38f@pws-pc.ntlworld.com> <131110183043.ZM21795@torch.brasslantern.com> <131111084228.ZM26372@torch.brasslantern.com> <20131112101139.31d67b73@pwslap01u.europe.root.pri> <20131112174805.26ecab48@pwslap01u.europe.root.pri> <20131112210424.177c035b@pws-pc.ntlworld.com> <20131113092831.2ed6ab94@pwslap01u.europe.root.pri> <20131113112112.1b080b79@pwslap01u.europe.root.pri> <131113080606.ZM11640@torch.brasslantern.com> <131117103047.ZM30518@torch.brasslantern.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 17 Nov 2013 10:30:47 -0800 Bart Schaefer wrote: > On Nov 16, 12:14pm, Martin Vaeth wrote: > } > } This patch implements a mechanism which supports "source/" subdirs > } in the function hierarchy: > > I'd rather these were not inside the tree like that. There should be an > entirely separate location for them. > > In fact, in thinking about it, furter, I believe we should maintain the > Completion/ and Functions/ trees as conceptually read-only at "make all" > time. Any files like _run_help and run-help that need to be generated > from a .in file should be processed by "make install" (install.fns rule) > directly into the $(sitefndir) target, and should never appear in the > Zsh build tree. I can see the potential confusion in having files that need processing in the same tree as files that get installed verbatim, although I didn't see it as necessarily a problem in practice, but the files should be generated at make time, not install time, otherwise it's inconsistent with the rest of the build system. Up to now, installation has been a straight copy and I don't see any point in changing that: it adds an extra point of failure (other than those applicable to copying, e.g. permissions), for one thing. I'm not even sure the config.status processing applicable to substitutions for .in files, which is what we want here (and I don't see any point in inventing a new form of processing), is designed to go straight to install directories. > Taking that as step further, I'm beginning to think the helpfiles should > also be generated by "make install" rather than being written to a tree > underneath Doc/. Again, this is inconsistent with other files that get installed, and also (which is really part of the same thing) means we can't supply them in the doc bundle with the other pre-generated documentation. In both cases, where they get written is another matter. We could have a parallel hierarchy Functions_pre for generated functions. The doc bundle isn't supposed to be standalone, it's supposed to give you additional files to install using the files from the normal build, so I don't think that's a limitation. So I'm not that fussed where the generated helpfiles go in the first instance. -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/