From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28414 invoked from network); 14 Jan 2004 15:56:51 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 14 Jan 2004 15:56:51 -0000 Received: (qmail 23953 invoked by alias); 14 Jan 2004 15:56:43 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19366 Received: (qmail 23922 invoked from network); 14 Jan 2004 15:56:43 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 14 Jan 2004 15:56:43 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [193.109.254.211] by sunsite.dk (MessageWall 1.0.8) with SMTP; 14 Jan 2004 15:56:43 -0000 X-VirusChecked: Checked X-Env-Sender: okiddle@yahoo.co.uk X-Msg-Ref: server-21.tower-36.messagelabs.com!1074095801!3125165 X-StarScan-Version: 5.1.15; banners=-,-,- Received: (qmail 8193 invoked from network); 14 Jan 2004 15:56:41 -0000 Received: from iris.logica.co.uk (158.234.9.163) by server-21.tower-36.messagelabs.com with SMTP; 14 Jan 2004 15:56:41 -0000 Received: from gmcs3.local ([158.234.142.61]) by iris.logica.co.uk (8.12.3/8.12.3/Debian -4) with ESMTP id i0EFueuB008722 for ; Wed, 14 Jan 2004 15:56:40 GMT Received: from gmcs3.local (localhost [127.0.0.1]) by gmcs3.local (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id i0EG1SI04154 for ; Wed, 14 Jan 2004 17:01:28 +0100 X-VirusChecked: Checked X-StarScan-Version: 5.0.7; banners=.,-,- In-reply-to: <66F451E8923A3D42B22434287141E2E3D1239B@mowp006a.ru001.siemens.net> From: Oliver Kiddle References: <66F451E8923A3D42B22434287141E2E3D1239B@mowp006a.ru001.siemens.net> To: "Zsh hackers list" Subject: Re: autoconf 2.5 (Re: PATCH: terminfo horor) Date: Wed, 14 Jan 2004 17:01:28 +0100 Message-ID: <4152.1074096088@gmcs3.local> On 9 Jan, Andrey wrote: > before starting to hack around configure we probably need to define the > final goal. For module build some options are The main goal I had in mind was just for the thing to actually compile on my machine without messy fiddling. > - 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) I'd also add that a significant goal should be to keep the end result as simple as possible because it could easily become very complex. > Supporting them off-tree facilitates independent modules development but I > have a feeling it is unlikely to be an issue in the near future :) A lot more would have to be changed too allow off-tree modules so it is probably best kept in-tree. > 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 Can we have module-specific m4 fragments included into the main configure script? > Having module detection in configure (as is done currently) prevents adding > per-module configure checks (at least, using autoconf language). Why? Does it really matter if we have redundant configure checks? Surely we need the result of some configure tests to determine which modules to build anyway. > 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. Controlling what modules are linked with configure --with options would probably be a lot nicer that the current file editing. Perhaps with separate options, e.g. --with-module-pcre or --with-module-pcre=dynamic. Oliver