From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5703 invoked from network); 4 Sep 2000 15:01:53 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Sep 2000 15:01:53 -0000 Received: (qmail 12033 invoked by alias); 4 Sep 2000 15:01:46 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12740 Received: (qmail 11989 invoked from network); 4 Sep 2000 15:01:46 -0000 Date: Mon, 04 Sep 2000 16:01:18 +0100 From: Peter Stephenson Subject: Re: Module system RE: 3.1.9-dev-6 In-reply-to: "Your message of Mon, 04 Sep 2000 18:23:21 +0400." <000101c0167b$ad951130$21c9ca95@mow.siemens.ru> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Message-id: <0G0D00FGZB2697@la-la.cambridgesiliconradio.com> Content-transfer-encoding: 7BIT > Add single parameter > > --enable-zsh-modules="module list" I came to the conclusion we had come to the limit of what we could easily do with configure: it's extremely uncomfortable for anything complicated, and we keep getting requests for things that configure can't do. It's extremely hard to upgrade; the code is spread all over, the configure options interact, and the active code is somewhere else entirely. It's hard to set up: you end up fiddling with command line options and rerunning configure. Furthermore, it's horrible to write in comparison with a shell-script-based system. So I would like to remove the module control stuff (which has appeared in the last couple of 3.1 releases) from configure and do it as suggested --- set up a file based on the modules that exist, and allow the installer to edit it. The subtext is, if people would prefer a purely configure-based system it's unlikely to be me that gets around to writing it any time in the foreseeable future. -- Peter Stephenson Software Engineer Cambridge Silicon Radio, Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070