RE: Module hierarchies, aliasing, and dependencies

["Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru>]

>
> It *was* my assumption that the file name relative to $module_path would
> be the single argument to zmodload when loading the module, but of course
> there's no particular reason to assume that, either.
>
> } zmodload -f /path/to/my/module.so zsh/zle
>
> That would be fine, except that it requires you to know the full path
> to the module and the shared object extension, so it won't work in a
> cross-platform way.  How about instead something like
>

It depends on usage pattern. I think about it as developers aid in the first
place. In this case you definitely know path name and extension :-)

But nothing prevents relative pathnames like

zmodload -f relative/path zsh/zle

that would be interpreted in usual way (search through module_path adding
system-specific extension).

>
> I suggest that, for the first pass, the "module identification" can be
> limited to the base name of the shared object; unless I misunderstand
> what you said about Windows DLLs, it won't work to load two DLLs with
> the same base name anyway (at least not without a major rewrite, and
> maybe not even then).
>

The worst case is that currently even zsh/foo and bar/foo may clash. But this
happens to my best knowledge only if we use implicit linking (I believe,
Microsoft calls it compile-time). We can load two DLLs with the same base
names using dlopen() and dlsym() will work correctly. IIRC :-) I must check.
What may not work, if zsh/bar depends on (is linked with) zsh/foo and my/bar
depends on my/foo. I am afraid, that Windows will search only one of */foo
DLLs even if we explicitly load both.


-andrej