RE: Module hierarchies, aliasing, and dependencies

["Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>]

>
> On Sep 10, 10:35pm, Zefram wrote:
> } Subject: Re: Module hierarchies, aliasing, and dependencies
> }
> } [E.g.] zsh/deltochar depends on zsh/zle: with dependencies set up right,
> } zsh/zle will be loaded automatically before zsh/deltochar.  But if you
> } load zsh/deltochar under the name "local/deltochar" (or just "deltochar",
> } or anything else) zsh/zle won't be loaded first, and so the load will fail
> } (unless zsh/zle was already loaded).
>
> I don't think this is really a problem -- the issue is not automatically
> discovering that local/deltochar depends on zsh/zle, it's discovering that
> local/zle has already substituted for zsh/zle when loading zsh/deltochar.
>
> Put another way, I'm quite happy to have to explicitly state dependency
> of local/deltochar on zsh/zle, external to any module.  However, if the
> user explicitly loads local/zle, I want zsh to discover that it does not
> also need to load zsh/zle at the time zsh/deltochar is loaded.
>

It looks, like both posters still assume that "file name" == "module name". I
do not see why it must be so. Module dependencies are stated in term of
"module" not "file". So, if I have my own  *module* zsh/deltochar (or zsh/zle)
that happen to reside in *file* /what/ever/local/deltochar.so or
/some/other/path/zle.so then I just need some way to say

zmodload -f /path/to/my/module.so zsh/zle

Of course, zmodload must check, that /path/to/my/module.so really defines
zsh/zle, but after that no changes are really needed to current module system
(but see below). So, what is needed

- add some module identification (this may be one more entry point - it is
probably the only way to do it, unless we want to reimplement runtime loader).

- separate module name and file name. Hey! we could even implement files that
define more than one module! :-)

> An alternate solution has just occurred to me ... in the setup function in
> local/zle, one could simply scan the module list for any module that has a
> dependency on zsh/zle, and substitute the name local/zle in its place.
> However, that would not help if `zmodload -d ... zsh/zle' was used after
> the local/zle setup function was called, so some additional magic would
> also be needed.
>

Unless I'm mistaken, this is completely redundant. The initial wish was to
load the *same* module from different place, not to load module under
different name?

> } There's another issue that on some systems name clashes between symbols
> } exported by different modules isn't permitted, so every module's boot
> } function has to be named differently, so we need to know the module's
> } internal name in order to call any code in it.  Loading under a different
> } name just won't work on that kind of system (as I mentioned upthread).
>
> Under what circumstances would it be necessary to call any code without
> knowing the actual name of the shared object?
>

The unfortunate problem is, that we may *need* the name of shared object. The
current state is, that modules have many cross-references. This works under
most modern Unix with ELF, because run-time linker (normally) does not care
where symbol is located (normally, because I have options to bind symbols to
specific objects at compile time). It means, that after
/what/ever/local/myzle.so was loaded it will satisfy implicit request for any
symbol from zle module.

But we have to deal with Cygwin. Import list for any module includes names off
DLL from which symbols are imported. And I got impression (still have not
confirmed), that this name is the same as DLL file name (at least, I was not
able to change it. It may be a problem of Cygwin tools). It means, that it may
not be possible to substitute zle with myzle at all.

The general solution is to get rid of all implicit cross references and use
only dlsym()'d objects. This will correctly work under Cygwin but it means
substantial rewrite (it may be automated. For every module get list of all
mod_exported symbols from another modules and put dlsym() calls for them into
setup function. Of course, we need some dlsym() wrapper to get real file name
from module name. Actually, sounds quite reasonable :-)

To summarize:

- I agree with one additional entry point for module name (it may just as well
be a simple string)
- we must distinguish between module name and file name. I suggest extending
zmodload to allow optional file name. It must check, of course, that this file
really defines requested module.
- all internal dependencies are in terms of mode names. After module has been
loaded, it is known under it's module name, and it's file name is of small (or
no) interest at all. That covers both Zefram and Bart's arguments.
- well, Cygwin case remains ... any ideas? Anybody knows internals of
Microsoft run-time linker?

-andrej