Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Adding (compiling) a module to already build Zsh
- X-seq: zsh-workers 39318
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>
- Subject: Re: Adding (compiling) a module to already build Zsh
- Date: Wed, 14 Sep 2016 10:54:47 +0200
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1473843288; bh=Bz1vRSvtmIe+TfFjEh9iM7+e1HjENMeQ5x/rqXXPAf0=; h=cc:In-reply-to:From:References:To:Subject:Date:From:Subject; b=DXkYnHI0aUYgYzWH0Zb0N915qSd9CEzbDCHGz4CFDewB5/+jNCKtI+115jrlcN0rQGjR4kGObvQBWtG29ZIXaiQmbHOPkEQiRzQzpB8b5zKCSYEZar58JUrlLP+PyjJ9pB7wKezAb31AvDbrk3XJiAPvVWtnOmr98+WqkSe7LVjh9vEM4TgOj2lNWfgjT2CmvzqFkjST9bEOT+VCRkO/SuidBWNmUAR+uR3b/K0GtzwFl5txRMgnPTNVKE6Jat20mjSKIhahDLZW0Moaq7vB8D6kVUfHVson8DetDzVh18JUAm5tt/qtfEGGsC8pz+KxBURLg7MywHZvpZBvPVEF1Q==
- In-reply-to: <CAKc7PVCy4R=Frg1FH_iBaT-BiWiO13p27VDyPX_x9AkT9rCX0w@mail.gmail.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CAKc7PVB+A2Pzjz5GF8MLT2j=fz+0JSLK9k2vkx2bt6ENRzirMw@mail.gmail.com> <160912103839.ZM25202@torch.brasslantern.com> <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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author