Static link of curses module

Static link of curses module

[Sebastian Gniazdowski]

Hello
Editing Src/Modules/curses.mdd, putting:
name=zsh/curses
link=static
load=no

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 file curses.o is linked to the zsh (Src/stamp-modobjs
contains it), however zmodload's output doesn't report curses module.
Tested on OS X and msys1.

Best regards,
Sebastian Gniazdowski

Re: Static link of curses module

[Sebastian Gniazdowski]

A mistake in email – the load should be "yes":
name=zsh/curses
link=static
load=yes

I now tested this on OSX - with "./configure --disable-dynamic",
FreeBSD 10.1 with "./configure --with-term-lib=ncurses", Ubuntu 12.10
"./configure --with-term-lib=ncurses", cygwin "./configure
--disable-dynamic", msys1 with implicit static only modules
(--disable-dynamic)

Best regards,
Sebastian Gniazdowski

On 27 September 2015 at 15:16, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> Hello
> Editing Src/Modules/curses.mdd, putting:
> name=zsh/curses
> link=static
> load=no
>
> 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 file curses.o is linked to the zsh (Src/stamp-modobjs
> contains it), however zmodload's output doesn't report curses module.
> Tested on OS X and msys1.
>
> Best regards,
> Sebastian Gniazdowski

Re: Static link of curses module

[Peter Stephenson]

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

Re: Static link of curses module

[Sebastian Gniazdowski]

On 27 September 2015 at 17:28, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> 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.

It works. It's interesting that zmodload can decipher "zsh/" found in
"zmodload zsh/curses". Apparently "zsh/curses" is the module's name,
not a path ("zsh/") and a name. I now can run zsh and zcurses on
msys1, after installing libtermcap and ncurses (the second one from
source).

Best regards,
Sebastian Gniazdowski

Re: Static link of curses module

[Sebastian Gniazdowski]

On 27 September 2015 at 18:04, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> not a path ("zsh/") and a name. I now can run zsh and zcurses on
> msys1, after installing libtermcap and ncurses (the second one from
> source).

For the record, libtermcap isn't needed, ncurses compiles without it,
and zsh can use ncurses instead of termcap (--with-term-lib=ncurses)

Best regards,
Sebastian Gniazdowski

Re: Static link of curses module

[Bart Schaefer]

On Sep 27,  4:28pm, Peter Stephenson wrote:
}
} Typically, you'd do this by editing config.modules rather than the .mdd

config.modules is generated from the .mdd and then is what gets used at
build time, so yeah.

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

Yeah, I don't think that was ever what it was intended to mean.  I think
the intent was that if the module has autoloads, then you don't have to
declare them with "zmodload -a".  It doesn't imply that load_module()
is actually called.

Look at the modules that have "load=yes" in the default .mdd file:

rlimits
sched
parameter
termcap
terminfo
zutil
(plus several in Zle)

Those all have autofeatures declared.  Then look at curses.mdd -- it
has "autobins" instead.  No other .mdd file has "autobins".

I think curses.mdd just got overlooked when we converted to the features
mechanism.  Try this?


diff --git a/Src/Modules/curses.mdd b/Src/Modules/curses.mdd
index 669c4f5..80c8f86 100644
--- a/Src/Modules/curses.mdd
+++ b/Src/Modules/curses.mdd
@@ -2,7 +2,7 @@ name=zsh/curses
 link='if test "x$ac_cv_func_initscr" = xyes && test "x$zsh_cv_path_curses_header" != x; then echo dynamic; else echo no; fi'
 load=no
 
-autobins="zcurses"
+autofeatures="b:zcurses"
 
 objects="curses.o"
 

Re: Static link of curses module

[Peter Stephenson]

On Sun, 27 Sep 2015 09:44:15 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> I think curses.mdd just got overlooked when we converted to the features
> mechanism.  Try this?
> 
> -autobins="zcurses"
> +autofeatures="b:zcurses"

Yes, that makes more sense.  It works transparently with no changes to
the mechanism.

pws