From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5327 invoked from network); 4 Sep 2000 14:23:36 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Sep 2000 14:23:36 -0000 Received: (qmail 7620 invoked by alias); 4 Sep 2000 14:23:25 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12738 Received: (qmail 7612 invoked from network); 4 Sep 2000 14:23:24 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer david.siemens.de) From: "Andrej Borsenkow" To: "Peter Stephenson" , "Zsh hackers list" Subject: Module system RE: 3.1.9-dev-6 Date: Mon, 4 Sep 2000 18:23:21 +0400 Message-ID: <000101c0167b$ad951130$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <0G0D00F738JX97@la-la.cambridgesiliconradio.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > > As things stand, the only thing I am at all likely to have a go at myself > before 4.0 is integrating the module system, unless somebody gets there > first. I have a few ideas about doing this: something to go in configure, > and something to go in the source code module system will be necessary, and > maybe some extra installation hooks (though they may be OK already). It > would probably be something like this: configure generates a file with > lists of modules (probably based on the .mdd files, which may therefore get > extended), functions and eventually (this won't happen without some extra > stuff in the documentation system) manual/info entries. Unlike the present > system, this will completely describe all modules, so you can turn on and > off compilation and installation just by changing an entry --- e.g. if you > decide to add zftp to a system without dynamic loading, you just change > `no' to `yes' and the functions get installed, too. This file is read by > everything which has to do with modules, and can be updated by hand > (probably configure therefore shouldn't modify an existing one). > > One of the .mdd additions would probably be a variable indicating whether > to compile by default; currently, if you have dynamic loading, everything > automatically gets compiled, which will be less and less useful as we get > more and more specialised modules (I have a module which talks to our > Bluetooth chip, which isn't a lot of use for most people). > This is the idea for configure time module selection I had. It was targeted at dynamic/static/linked-in selection, but could be extended to cover all the above as well (by suitable .mdd extension). Add single parameter --enable-zsh-modules="module list" Module list has format: =(skip|static|dynamic)[,autoload] ... where = (module name|group name|"default") Examples (assuming, std are modules that are currently marked for autoload): - current default for dynamic build: --enable-zsh-modules="default=dynamic std=dynamic,autoload" - current default for static build: --enable-zsh-modules="default=skip std=static,autoload" I intended to set modules group in .mdd file. In this way, if we add new module to e.g. ZLE, it will be automatically covered by, say zle=static,autoload This, of coursem needs some precedence resolution rules, but it is pretty straightforward. The whole is intended to take place at configure time (and not at make) With suitable .mdd files and build system we can incorporate almost anything here. Comments? -andrej