From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9695 invoked from network); 9 Jan 2004 09:31:55 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 9 Jan 2004 09:31:55 -0000 Received: (qmail 14001 invoked by alias); 9 Jan 2004 09:31:48 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19355 Received: (qmail 13947 invoked from network); 9 Jan 2004 09:31:48 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 9 Jan 2004 09:31:48 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [192.35.17.2] by sunsite.dk (MessageWall 1.0.8) with SMTP; 9 Jan 2004 9:31:47 -0000 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i099VlS25376; Fri, 9 Jan 2004 10:31:47 +0100 (MET) Received: from mowp006a.ww600.siemens.net (mowp006a.ru001.siemens.net [163.242.193.6]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i099VkL13051; Fri, 9 Jan 2004 10:31:46 +0100 (MET) Received: by mowp006a.ru001.siemens.net with Internet Mail Service (5.5.2657.72) id ; Fri, 9 Jan 2004 12:31:45 +0300 Message-ID: <66F451E8923A3D42B22434287141E2E3D1239B@mowp006a.ru001.siemens.net> From: Borzenkov Andrey To: "'Oliver Kiddle'" , "'Zsh hackers list'" Subject: RE: autoconf 2.5 (Re: PATCH: terminfo horor) Date: Fri, 9 Jan 2004 12:31:44 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain > Andrey wrote: > > > > right; but to do it we need make configure puts into config.status (or > as > > init part of running config.modules.sh) information that modules may > need to > > make decision. Using cache variables was big mistake to start with :( > > Why do the decisions modules make need to be re-made when config.status > runs? Can't we just evaluate decisions once, in configure, and store the > answers in config.status? > well, that's what it always did actually :) before starting to hack around configure we probably need to define the final goal. For module build some options are - module source location (in-tree vs. off-tree) - module detection (pre-configure, configure, post-configure) - module configuration (single configure possibly built from different sources vs. per-module configure) - build time (in-tree vs. off-tree) having modules always in tree makes it possible to automate module detection completely; i.e. Makfefile can just always rescan for changed modules and rebuild necessary files if list has changed. Supporting them off-tree facilitates independent modules development but I have a feeling it is unlikely to be an issue in the near future :) Having separate per-module configure has one problem of passing results of main configure testing down because 2.5 disables caching by default. I could not find suitable solution to this problem unless recent autoconf has changed it. Besides to really utilize autoconf features list of sub-configure has to be statically included in top-level script. Advantage it has is that user can just drop in module source and does not need to worry about having suitable autoconf version Having module detection in configure (as is done currently) prevents adding per-module configure checks (at least, using autoconf language). So overall I am inclined to the build process that - assumes all modules in-tree - builds initial modules list as part of preconfig and adds rule to Makefile to recheck and rebuild it later - (re-)builds configure from snippets optionally supplied by modules - provides --with-modules and --with-static-modules (with wildcard support) to control which modules are included and which are built statically into zsh, eliminating any auto-generated file editing. Comments? -andrey