zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: Sebastian Gniazdowski <sgniazdowski@gmail.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Adding (compiling) a module to already build Zsh
Date: Wed, 14 Sep 2016 10:54:47 +0200	[thread overview]
Message-ID: <45670.1473843287@hydra.kiddle.eu> (raw)
In-Reply-To: <CAKc7PVCy4R=Frg1FH_iBaT-BiWiO13p27VDyPX_x9AkT9rCX0w@mail.gmail.com>

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


  reply	other threads:[~2016-09-14  9:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-12  6:12 Sebastian Gniazdowski
2016-09-12 17:38 ` Bart Schaefer
2016-09-14  7:16   ` Sebastian Gniazdowski
2016-09-14  8:54     ` Oliver Kiddle [this message]
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

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=45670.1473843287@hydra.kiddle.eu \
    --to=okiddle@yahoo.co.uk \
    --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).