Re: Modules dependencies RE: PATCH: zftp/tcp abstraction

[Zefram <zefram@fysh.org>]

I generally support Andrej's suggestion, with just a couple of issues:

Bart Schaefer wrote:
>I object to any solution which requires that a statically linked binary
>rely upon any external files.  I can't tell for certain whether that is
>the case with your suggestion, but that's the impression I get.

It's only the case if there are external .zmd files for the internally
linked modules.  If we instead build this data into the executable,
then there is no problem.

>} - 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)

Here, we must be sure to load the module object from the proper directory
-- we need the filename, not the soname.

On Bart's suggestions:

>Why can't the module definition file itself be a loadable module?

Doing that would run into issues of symbol name clashes, but it is
surmountable, as we have already solved that problem for the modules
themselves.  However, module definition files being code just seems like
a bad idea; I'd be happier with them being plain old data, that can be
manipulated as data.  It doesn't seem that we gain anything by using
a shared object here, and we'd lose some flexibility (think what other
information we might want to put in the .zmd, and other ways we'd like
to use the information).

>of this object is derived from the name of the base module, e.g. for
>zsh/zftp the name might be zsh/ld/zftp (and zsh/net/ld/tcp, etc.).

Creating extra modules that are visible in the module namespace would
be a bad idea.  At minimum, it exposes too much of the implementation,
forcing us to retain this method of handling loadable modules even if
we come up with a better way.

-zefram