From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13370 invoked from network); 26 Jun 2001 11:26:57 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 26 Jun 2001 11:26:57 -0000 Received: (qmail 7612 invoked by alias); 26 Jun 2001 11:26:09 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15091 Received: (qmail 7585 invoked from network); 26 Jun 2001 11:26:08 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer goliath.siemens.de) From: "Andrej Borsenkow" To: Subject: RE: Modules dependencies RE: PATCH: zftp/tcp abstraction Date: Tue, 26 Jun 2001 15:26:44 +0400 Message-ID: <001301c0fe32$e11f5200$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Importance: Normal > > Andrej Borsenkow wrote: > >To make it work in general every module needs a standard function, let's > >call it dep_, that is autogenerated out of moddeps and called > before module > >is attempted to be loaded to register dependencies. > > Problem is you can't call that function without loading the module, and > you can't successfully load the module until you've got that information. > If there were an easy solution we'd have implemented it as soon as we > came up with the module system. > Here is suggested change to current module system. It is actually pretty trivial to implement and may have additional advantages ... - module is represented by its module definition file. It is basically mdd file with all makefile fragments stripped and any shell code replaced by final value. To avoid confusion with original mdd, let's call it zmd (Zsh Module Definition). The additional property is full name of binary DSO object, e.g. soname. - when you open a module, zsh opens zmd file. It then loads all needed modules (as in moddeps) and after that loads modules object itself (as in soname) - zmd file is always installed for both linked-in and external modules. It eliminates need to build extra list at compile-time. - zsh _may_ scan $module_path and autoload objects from those modules with load=yes at startup. Or it even can do it when $module_path changes (but see *1). This makes it possible to have a single binary and simply drop new module in place that may be of some use for packagers. This does not seem very hard to implement (the ugliest part is parsing of zmd files; do we have something ready in zsh so as not to reinvent the wheel)? Comments? -andrej *1 When (re)scanning $module_path the problem is, what to do with currently loaded modules. Consider the case: module zsh/mod1 provides foo and bar and is loaded module zsh/mod2 provides baz and bar and is being scanned Zsh first adds baz, then it adds bar and gets an error. We possibly have to remove baz now (else, it will try to load zsh/mod2 on access to baz and this will silently redefine bar). P.S. We can even completely ignore file name and rely on name= in zmd file. That gives natural way to directly load any module by its path name.