Building a new ZSH module outside the ZSH source tree

Building a new ZSH module outside the ZSH source tree

[tetsujin]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

Hi there, I'm working on a library called "Shell-Pepper" - the idea is
to provide some added functionality to multiple different shells via
loadable modules (when it's necessary or at least beneficial to do so)
and shell scripts...

Anyway, so far the library has just a few commands (some of which are
already provided as part of zsh - I think it's pretty cool that zsh
already provides a module for connecting to Unix Domain Sockets) - and
so far, only for Bash and Korn Shell. It seems like zsh has a fairly
nice programming interface for modules, but I'm not really clear on
the process for building a module without tying it into the zsh build
system.

In particular, the only examples of zsh modules I have are part of the
zsh distribution, in Src/Modules. Each one includes C source and  a
module description file (.mdd) - and sometime during the build,
Src/Modules/Makefile and Makefile.in are generated, and the contents
of these (particularly the generation of module.mdh and module.epro)
are a bit arcane. I can copy the example module and create another zsh
module in zsh/Src/Modules, and build it. But because shell-pepper is
aiming to support multiple shells, a lot of its functionality is
factored out into a "common" build directory. I'm not sure it quite
fits into this build model, and I'd rather stick to the model I've got
anyway - feed the location of the build trees for the different shells
into my build system and build from my project tree.

So I don't really know if there's been much call in the past for
building ZSH modules outside the ZSH source tree, I don't know if
there's a good solution for this at this point. But if somebody on the
list could help me out with this, I'd appreciate it.

---GEC

Re: Building a new ZSH module outside the ZSH source tree

[Bart Schaefer]

On May 24,  2:57pm, tetsujin@scope-eye.net wrote:
}
} nice programming interface for modules, but I'm not really clear on
} the process for building a module without tying it into the zsh build
} system.

I haven't actually tried the following yet.

--- Forwarded mail from Sebastian Gniazdowski <psprint2@fastmail.com>

X-Seq: 40477
From: Sebastian Gniazdowski <psprint2@fastmail.com>
To: zsh-workers@zsh.org
Subject: Modules can be built outside Zsh; custom version of autoload builtin
Date: Wed, 01 Feb 2017 09:48:51 -0800

Hello
1/ Turned out that it's easy to build Zsh modules away from complete
source. Here is a minimum build setup:

https://github.com/psprint/zplugin/tree/6a4ba014eb167cbc97353f0a59e63f62bd6442bc/zmodules

Tested this on OS X. I can load module built with Zsh 5.3.1 features
even on Apple-provided 5.0.8. It's only that lazy binding will fail, if
I call non-existent (in 5.0.8) function. So, plugin creators can
actually provide binary parts, what I'm intending to do too, in Zplugin.

Re: Building a new ZSH module outside the ZSH source tree

[tetsujin]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]


 >On May 24, 2:57pm, tetsujin@scope-eye.net wrote:
 >}
 >} I'm not really clear on the process for building a module
>} without tying it into the zsh build system.
>
 >I haven't actually tried the following yet.
>
> --- Forwarded mail from Sebastian Gniazdowski
<psprint2@fastmail.com>
>
> Hello
 >1/ Turned out that it's easy to build Zsh modules away from complete
 >source. Here is a minimum build setup:
>
>
https://github.com/psprint/zplugin/tree/6a4ba014eb167cbc97353f0a59e63f62bd6442bc/zmodules

Thanks! Unfortunately it seems this project gets around the issue by
duplicating the zsh source tree and build environment, and planting
the zdharma/zplugin project within it.

It gets the job done, but it's not really ideal. I guess the main
thing (perhaps) is the *.mdh file that gets generated - what it does,
and how I can generate it myself.

"What it does", I guess, is set a bunch of defines to change the
module load/unload functions' names to a form specific to the package
(#define boot_ boot_zdharmaQszplugin for instance) and set some
defines prior to including shell headers...

The way to generate it, I guess, is to run zsh/Src/mkmakemod.sh, which
produces the Makefile for the module, which in turn generates the
module headers and other files.

Perhaps the best answer is to call into the script from my module's
build system, and then use the Makefile it generates. Perhaps that
could even work without having to place my module in a subdirectory of
the shell's build tree? (Not sure about that one.)

---GEC

Re: Building a new ZSH module outside the ZSH source tree

[Sebastian Gniazdowski]

On 25 maja 2017 at 00:41:41, tetsujin@scope-eye.net (tetsujin@scope-eye.net) wrote:
> Perhaps the best answer is to call into the script from my module's
> build system, and then use the Makefile it generates. Perhaps that
> could even work without having to place my module in a subdirectory of
> the shell's build tree? (Not sure about that one.)

I think it will work, all is needed is what is automatically generated from .c files – functions marked with /**/ are exported, etc. I didn't do this, have this in back of my head, currently I focus on the body of the topic – the actual modules – having the Zsh's configure script handling things for me.

One thing: from Zsh 5.2 there was introduced addmodulefd() call. Created file descriptors should be registered with it. So module will need #ifdefs disabling this call to properly load on zsh-5.0.8 or similar. I think what the addmodulefd() does isn't actually or fully used within shell, the fd-management still actually relies on dup, dup2 knowing which FDs are taken and which are free. Am I right, could someone clarify?

I'm looking for a way to disable addmodule fd call, either at compile time (would have to guess that user has zsh < 5.2, or use --disable-addfd configure option), or at run-time.

-- 
Sebastian Gniazdowski
psprint /at/ zdharma.org

Re: Building a new ZSH module outside the ZSH source tree

[George]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

On Thu, 2017-05-25 at 15:00 +0200, Sebastian Gniazdowski wrote:
> > 
> > One thing: from Zsh 5.2 there was introduced addmodulefd() call. Created file descriptors should be registered with it. So module will need
> > #ifdefs disabling this call to properly load on zsh-5.0.8 or similar. I think what the addmodulefd() does isn't actually or fully used within
> > shell, the fd-management still actually relies on dup, dup2 knowing which FDs are taken and which are free. Am I right, could someone clarify?
> > 
> > 
Interesting. Thanks for the heads up, my familiarity with the zsh codebase is pretty limited at this point, but handling FDs (and correctly) will be
important for what I have in mind, so this is useful information, and a detail I could have easily overlooked.##SELECTION_END##