* Adding (compiling) a module to already build Zsh @ 2016-09-12 6:12 Sebastian Gniazdowski 2016-09-12 17:38 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Sebastian Gniazdowski @ 2016-09-12 6:12 UTC (permalink / raw) To: Zsh hackers list Hello, on IRC someone asked how to "add gdbm". I wonder if the module can be easily added to already installed Zsh, if it's not already bundled? There should be something like Linux kernel-headers-*.(deb,rpm,etc.), however, I think gdbm and pcre add linkage to additional libraries to the Zsh binary itself. I guess there will be more obstacles, but who knows, maybe it's possible? It would be then possible to do following: bundle module source together with plugin (yeah, the current state of art Oh-My-Zsh plugin architecture's) and build the module at first load of the plugin. Best regards, Sebastian Gniazdowski ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding (compiling) a module to already build Zsh 2016-09-12 6:12 Adding (compiling) a module to already build Zsh Sebastian Gniazdowski @ 2016-09-12 17:38 ` Bart Schaefer 2016-09-14 7:16 ` Sebastian Gniazdowski 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2016-09-12 17:38 UTC (permalink / raw) To: Zsh hackers list On Sep 12, 8:12am, Sebastian Gniazdowski wrote: } } on IRC someone asked how to "add gdbm". I wonder if the module can be } easily added to already installed Zsh, if it's not already bundled? It should be possible to do this provided that (a) the zsh source matching the installed binary is available to compile against and (b) the installed binary was compiled with dynamic linkage enabled. What won't work is any automatic autoloads of the builtins etc. from any module added later. I can't think of a reason explicit "zmodload" wouldn't work, though, assuming the .so file was in a $module_path directory. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding (compiling) a module to already build Zsh 2016-09-12 17:38 ` Bart Schaefer @ 2016-09-14 7:16 ` Sebastian Gniazdowski 2016-09-14 8:54 ` Oliver Kiddle 2016-09-14 15:09 ` Lawrence Velázquez 0 siblings, 2 replies; 8+ messages in thread From: Sebastian Gniazdowski @ 2016-09-14 7:16 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh hackers list On 12 September 2016 at 19:38, Bart Schaefer <schaefer@brasslantern.com> wrote: > On Sep 12, 8:12am, Sebastian Gniazdowski wrote: > } > } on IRC someone asked how to "add gdbm". I wonder if the module can be > } easily added to already installed Zsh, if it's not already bundled? > > It should be possible to do this provided that > (a) the zsh source matching the installed binary is available to > compile against and Could be something like the commonly occurring package kernel-headers-*.(deb|rpm|etc.) created, with mostly header files constituting a build environment (source files are rather not needed?) ? It would be cool thing from one other reason. For example, there is gdbm module for Zsh. Its features make it capable of rising Zsh code to another level. However, it is rarely available in distributed Zsh packages (licensing issue? I'm not sure if license issue doesn't apply only to pcre module). However, with easily available build environment one would be able to distribute a gdbm module together with his plugin and this way overcome licensing issue. Best regards, Sebastian Gniazdowski ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding (compiling) a module to already build Zsh 2016-09-14 7:16 ` Sebastian Gniazdowski @ 2016-09-14 8:54 ` Oliver Kiddle 2016-09-14 16:19 ` Bart Schaefer 2016-09-14 19:03 ` Mikael Magnusson 2016-09-14 15:09 ` Lawrence Velázquez 1 sibling, 2 replies; 8+ messages in thread From: Oliver Kiddle @ 2016-09-14 8:54 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: Zsh hackers list Sebastian Gniazdowski wrote: > > On Sep 12, 8:12am, Sebastian Gniazdowski wrote: > > } I think gdbm and pcre add linkage to additional libraries to > > } the Zsh binary itself. You can usually prevent that with something like LDFLAGS='-Wl,--as-needed' Depending on you linker, the option might be -zignore. Or you can retrospectively remove the library from the NEEDED list with a tool like patchelf. The limitation is really with autoconf or at least our use of it. We add checks for libraries such as pcre and it adds -lpcre to the global list of linker options. I don't know whether anything has changed in autoconf to make it easier to limit that so it would only be used when linking the pcre module - anyone? > Could be something like the commonly occurring package > kernel-headers-*.(deb|rpm|etc.) created, with mostly header files > constituting a build environment (source files are rather not needed?) That would amount to a make target named something like install-headers to dump .h files in $prefix/include/zsh. Except we'd need to decide between dumping them all there or first stripping them down to a minimum. Many of the prototypes are autogenerated with makepro.awk and that mechanism ties in to aspects of the module mechanism. So, for example, an obvious function to include in the module interface might be addhookdefs but the prototype is in module.epro. This may not be a problem as such but it'd need someone who understands what's going on in that area. Perhaps, we could have another tag like mod_export for things we want to be part of the public interface. It would then need someone to go through the internal interfaces of zsh and decide what should be included in the external module interface. We may want only part of zsh.h included. It'd also be good if things were stuctured so that a module wouldn't need changes in order to be moved into the zsh tree or to be built with include files taken from a zsh source tree instead of a -dev package installation. > ? It would be cool thing from one other reason. For example, there is > gdbm module for Zsh. Its features make it capable of rising Zsh code > to another level. However, it is rarely available in distributed Zsh It might also benefit other things like the zython module that was posted a while back. Oliver ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding (compiling) a module to already build Zsh 2016-09-14 8:54 ` Oliver Kiddle @ 2016-09-14 16:19 ` Bart Schaefer 2016-09-14 19:03 ` Mikael Magnusson 1 sibling, 0 replies; 8+ messages in thread From: Bart Schaefer @ 2016-09-14 16:19 UTC (permalink / raw) To: Zsh hackers list On Sep 14, 10:54am, Oliver Kiddle wrote: } } Many of the prototypes are autogenerated with makepro.awk and that } mechanism ties in to aspects of the module mechanism. So, for example, an } obvious function to include in the module interface might be addhookdefs } but the prototype is in module.epro. This may not be a problem as such } but it'd need someone who understands what's going on in that area. This. It's difficult enough right now to add a module directly to the full zsh tree, much less tease apart all the bits that would need to be teased in order to build with only a few pre-existing headers. Packages like libapreq (mod_perl) and the old X11 had similar problems back in the day. (I haven't built loadable modules against any of their successors in many years, so I don't know the current state.) The decisions we made with .epro files and awk scripts were all good ones at the time. If we could find an expert on the current state of dynamic loading on a variety of platforms, it would be very helpful. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding (compiling) a module to already build Zsh 2016-09-14 8:54 ` Oliver Kiddle 2016-09-14 16:19 ` Bart Schaefer @ 2016-09-14 19:03 ` Mikael Magnusson 2016-09-15 12:22 ` Sebastian Gniazdowski 1 sibling, 1 reply; 8+ messages in thread From: Mikael Magnusson @ 2016-09-14 19:03 UTC (permalink / raw) To: Oliver Kiddle; +Cc: Sebastian Gniazdowski, Zsh hackers list On Wed, Sep 14, 2016 at 10:54 AM, Oliver Kiddle <okiddle@yahoo.co.uk> wrote: > Sebastian Gniazdowski wrote: >> > On Sep 12, 8:12am, Sebastian Gniazdowski wrote: > >> > } I think gdbm and pcre add linkage to additional libraries to >> > } the Zsh binary itself. > > You can usually prevent that with something like > LDFLAGS='-Wl,--as-needed' > Depending on you linker, the option might be -zignore. > > Or you can retrospectively remove the library from the NEEDED list with > a tool like patchelf. > > The limitation is really with autoconf or at least our use of it. > We add checks for libraries such as pcre and it adds -lpcre to the > global list of linker options. I don't know whether anything has changed > in autoconf to make it easier to limit that so it would only be used > when linking the pcre module - anyone? http://cgit.mika.l3ib.org/cgit/zsh-cvs/commit/?h=a095c720fff0893b9f1ca3f96bb28de125aa155f I did this at least 5 years ago so I didn't know as much then as I do know about autoconf, but I think AC_CHECK_LIB is a convenience macro for something that first checks if a lib is linkable, and then adds it to the list of things to link to globally. We could just expand those to the full thing that only does the check without adding, and since the lib is always the same, the part of the patch that has the unconditional lib names in the .mdd files should be fine? https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Libraries.html ah, actually we can just provide the action-if-found action and it won't add the name to LIBS for us, even better. -- Mikael Magnusson ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding (compiling) a module to already build Zsh 2016-09-14 19:03 ` Mikael Magnusson @ 2016-09-15 12:22 ` Sebastian Gniazdowski 0 siblings, 0 replies; 8+ messages in thread From: Sebastian Gniazdowski @ 2016-09-15 12:22 UTC (permalink / raw) To: Mikael Magnusson; +Cc: Oliver Kiddle, Zsh hackers list On 14 September 2016 at 21:03, Mikael Magnusson <mikachu@gmail.com> wrote: > http://cgit.mika.l3ib.org/cgit/zsh-cvs/commit/?h=a095c720fff0893b9f1ca3f96bb28de125aa155f > > I did this at least 5 years ago so I didn't know as much then as I do > know about autoconf, but I think AC_CHECK_LIB is a convenience macro > for something that first checks if a lib is linkable, and then adds it > to the list of things to link to globally. We could just expand those > to the full thing that only does the check without adding, and since > the lib is always the same, the part of the patch that has the > unconditional lib names in the .mdd files should be fine? > > https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Libraries.html > ah, actually we can just provide the action-if-found action and it > won't add the name to LIBS for us, even better. I once proposed update of configure when I at Ubuntu 14.04 observed, that when the terminal handling library is detected to be terminfo, Zcurses is not being build. I was warned that the "link modules' libraries to Zsh binary" is dictated by traits of some platforms, so if Zsh binary doesn't have ncurses, then any module also can't have it, and thus Zcurses is not build. I recall analyzing configure.ac and seeing there a precedence list of terminal handling libraries, when I wondered why configure ends with "-ldl -ltinfo -lrt -lm -lc", without -lncurses (ran the configure on Ubuntu 14.04 laptop right now). Being afraid about Zcurses future, I want to say that possibly altered configure.ac should strive for always building Zcurses, because it is an important module, maybe currently I'm the single person that's going to prove that, but I will with my new plugin which will change the way shell is used and put in shadow fish and bash. Zcurses is an asset, together with loadable modules, rich flags (e.g. [[ ${(M)${(f)"$(<$f)"}:#$query} ]] as replacement for forking for grep), patterns, etc. One can code like in Ruby, what I proved with zsh-navigation-tools that supports 120k-150k elements in the selectable list function n-list. Of course Zsh coding style has its long learning curve, I code for about 14 months and constantly improve, and I must say that many other plugin authors devote say 1 month for a plugin, when I constantly updated ZNT for 10 months. In short, Zsh can have developer community (already has, but they code close to ABSGuide and don't devote enough time) writing software thanks to well established platform, and "Zcurses everywhere" is important part of that platform, and not requiring that Zsh binary is linked to what modules are linked will allow to do "Gdbm everywhere" etc. Best regards, Sebastian Gniazdowski ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding (compiling) a module to already build Zsh 2016-09-14 7:16 ` Sebastian Gniazdowski 2016-09-14 8:54 ` Oliver Kiddle @ 2016-09-14 15:09 ` Lawrence Velázquez 1 sibling, 0 replies; 8+ messages in thread From: Lawrence Velázquez @ 2016-09-14 15:09 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: zsh-workers > On Sep 14, 2016, at 3:16 AM, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > > it is rarely available in distributed Zsh packages (licensing issue? > I'm not sure if license issue doesn't apply only to pcre module). > However, with easily available build environment one would be able to > distribute a gdbm module together with his plugin and this way > overcome licensing issue. Depends on the system vendor -- for instance, Linux distributions are fine with the GPL requirement, but Apple won't ship GPL 3 software. I also expect that package maintainers just don't think it's worth adding the gdbm dependency, although I do ship zsh/gdbm (and zsh/pcre) in MacPorts. vq ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-09-15 12:29 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-09-12 6:12 Adding (compiling) a module to already build Zsh Sebastian Gniazdowski 2016-09-12 17:38 ` Bart Schaefer 2016-09-14 7:16 ` Sebastian Gniazdowski 2016-09-14 8:54 ` Oliver Kiddle 2016-09-14 16:19 ` Bart Schaefer 2016-09-14 19:03 ` Mikael Magnusson 2016-09-15 12:22 ` Sebastian Gniazdowski 2016-09-14 15:09 ` Lawrence Velázquez
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).