zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: Sebastian Gniazdowski <sgniazdowski@gmail.com>
Cc: zsh-workers@zsh.org
Subject: Re: Static link of curses module
Date: Sun, 27 Sep 2015 16:28:35 +0100	[thread overview]
Message-ID: <20150927162835.4297b94c@ntlworld.com> (raw)
In-Reply-To: <CAKc7PVAQcCjkTnrdL1-8CNCsPSkRdMvwTcNS4GOUtZd3f+XnUg@mail.gmail.com>

On Sun, 27 Sep 2015 15:16:10 +0200
Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> Hello
> Editing Src/Modules/curses.mdd, putting:
> name=zsh/curses
> link=static
> load=yes
> 
> to the beginning there (the script that's there by default doesn't
> work) doesn't result in availability of the module (in the produced
> zsh).

(the above emended as in the follow-up).

The infrastrcture for handling modules doesn't get much love and
attention and is inadequate in many respects.  (In constrast, so far as
I know. the module code within the shell to deal with modules after the
build system has done its job is generally effective.)

Typically, you'd do this by editing config.modules rather than the .mdd
file, but I think the result is the same.  The module is correctly
linked in statically, but isn't actually loaded until you use zmodload,
or mark something for autoload and then use it.

I'm not sure how this is supposed to work.  I can see the module being
registered automatically, but I don't see any evidence that there was
ever a mechanism for running the request "load_module" based on
load=yes.  zsh/main is specially handled, as is zsh/zle and completion,
and the autoload mechanism means that you can cause the module to be
loaded based on configuration, but that looks like it.  I may be looking
in the wrong place.

This isn't generally a problem --- you're generating a variant of the
shell that has expectations about the availability of commands
incompatible with standard builds, i.e. you can run zcurses without any
preliminaries --- but is typical of the problems facing module
developers.

I don't see why bltinmods.list shouldn't be able to do the load_module()
after the register_module() if load=yes, but I don't know why it
doesn't.

pws


  parent reply	other threads:[~2015-09-27 15:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-27 13:16 Sebastian Gniazdowski
2015-09-27 13:45 ` Sebastian Gniazdowski
2015-09-27 15:28 ` Peter Stephenson [this message]
2015-09-27 16:04   ` Sebastian Gniazdowski
2015-09-27 17:17     ` Sebastian Gniazdowski
2015-09-27 16:44   ` Bart Schaefer
2015-09-28  8:35     ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150927162835.4297b94c@ntlworld.com \
    --to=p.w.stephenson@ntlworld.com \
    --cc=sgniazdowski@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).