From: Andy Patterson <ajpatter@uwaterloo.ca>
To: Pierre Neidhardt <mail@ambrevar.xyz>
Cc: 32770@debbugs.gnu.org
Subject: bug#32770: Packaging SLIME/SWANK as Common Lisp library
Date: Fri, 5 Oct 2018 00:56:52 -0400 [thread overview]
Message-ID: <20181005005652.29b18650@mailservices.uwaterloo.ca> (raw)
In-Reply-To: <87k1mym7kb.fsf@ambrevar.xyz>
Hi Pierre,
I've seen your later e-mail but I'd still like to answer some of your
questions here.
On Thu, 04 Oct 2018 10:37:08 +0200
Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> CC-ing Ludovic and Ricardo if they want to chime in.
>
> Thanks for the feedback, Andy, so invaluable as always.
>
> > I've been using a cffi consumer for a while now, and my approach for
> > that package was to update references to library and header files
> > with the full paths to their respective store items.
>
> Cool! Can you share this package? Or provide an example?
> Can't wait to get this up and running!
Sure, I'll append it.
>
> > Adding to *foreign-library-directories* at compile time may allow a
> > package to compile, but I get the feeling that it may not have the
> > desired effect when you try to load the package later on.
>
> Why? In my experience it works for a compiled Next executable.
I assume that you created this executable by saving the lisp image? If
that's the case, then it probably saved your
*foreign-library-directories* with the values you added to it. What
I'm considering is consumers of the libraries which should still work
if you load them from a fresh lisp session with no configuration.
I haven't looked into it yet but I don't think loading the library
would work in that case.
>
> > I guess another approach we could take if replacement is undesirable
> > would be to modify the cffi package to honour some environment
> > variable for its default, and then add that variable to the search
> > path for cffi.
>
> The cffi:*foreign-library-directories* approach got recommended to me
> on the CFFI mailing list. I find it similar to what you want, a sort
> of environment variable (a search-path global variable). I haven't
> looked into Nix.
>
> > I personally tend to favour replacement, but others could chime in
> > here as well since this problem isn't specific to lisp packaging.
>
> Could this be automated? What I like with
> cffi:*foreign-library-directories* is that we could automatically push
>
> (string-append (assoc-ref inputs "foo") "/lib)
>
> to it so that packages only have to write something like
>
> #:cffi-packages (list ,cl-sqlite ,cl-foo...)
>
Based on what you've written here, I guess that you're thinking of
adding to the *foreign-library-directories* for the consumers of
cffi-based packages. I thought you meant to do it for those packages
themselves. I think that might require some packages to propagate the
c libraries that they depend on.
In terms of automating things, it might be possible to do something
with *foreign-library-directories* in the asd files that we generate.
To be honest though, I think the fact that replacement can't be
automated is more of a bug in the libraries' build tooling. What I'm
thinking of is something like a configure script to set the library
paths before building is done. I think there are some examples of
guile projects which do just that. It might be something that we could
discuss with the lisp and asdf community.
--
Andy
---
I think this package might include some dependencies that aren't
upstreamed yet but it should provide the gist of it.
(define sbcl-cl-freetype2
(let ((revision "1")
(commit "5e4c9ff898f84c888f7e4bfb3402ee35abbf8ad9"))
(package
(name "sbcl-cl-freetype2")
(version (string-append "1.1-" revision "." (string-take commit
7))) (source
(origin
(method git-fetch)
(uri
(git-reference
(url "https://github.com/rpav/cl-freetype2.git")
(commit commit)))
(sha256
(base32
"0xmpswm65g5qq85n9nl5blqij2hw4nd4nc143nxhc77w49nf613d")) (file-name
(string-append "cl-freetype2-next-" version "-checkout"))))
(build-system asdf-build-system/sbcl)
(inputs
`(("freetype" ,freetype)
("sbcl-alexandria" ,sbcl-alexandria)
("sbcl-cffi" ,sbcl-cffi)
("sbcl-trivial-garbage" ,sbcl-trivial-garbage)))
(native-inputs
`(("tests:cl-fiveam" ,sbcl-fiveam)
("asdf:cl-cffi-grovel" ,sbcl-cffi-grovel)))
(arguments
'(#:phases
(modify-phases %standard-phases
(add-after 'unpack 'fix-paths
(lambda* (#:key inputs #:allow-other-keys)
(define freetype (assoc-ref inputs "freetype"))
(substitute* "src/ffi/ft2-lib.lisp"
(("libfreetype" all) (string-append
freetype "/lib/" all)))
(substitute* "src/ffi/grovel/grovel-freetype2.lisp"
(("/usr/include") (string-append freetype
"/include")))))))) (home-page "https://github.com/rpav/cl-freetype2")
(synopsis "Common Lisp bindings for Freetype 2")
(description "This is a general Freetype 2 wrapper for Common Lisp
using CFFI. It's geared toward both using Freetype directly by
providing a simplified API, as well as providing access to the
underlying C structures and functions for use with other libraries
which may also use Freetype.")
(license license:bsd-3))))
next prev parent reply other threads:[~2018-10-05 5:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-19 7:19 bug#32770: Packaging SLIME/SWANK as Common Lisp library Pierre Neidhardt
2018-09-29 19:16 ` Andy Patterson
2018-09-30 21:27 ` Pierre Neidhardt
2018-09-30 21:46 ` Pierre Neidhardt
2018-10-01 13:53 ` Pierre Neidhardt
2018-10-02 8:38 ` Andy Patterson
2018-10-02 8:55 ` Andy Patterson
2018-10-02 10:24 ` Pierre Neidhardt
2018-10-03 5:22 ` Andy Patterson
2018-10-03 18:34 ` Pierre Neidhardt
2018-10-03 19:48 ` Pierre Neidhardt
2018-10-04 5:03 ` Andy Patterson
2018-10-04 8:37 ` Pierre Neidhardt
2018-10-04 18:08 ` Ricardo Wurmus
2018-10-04 20:38 ` Pierre Neidhardt
2019-10-06 11:53 ` Pierre Neidhardt
2018-10-05 4:56 ` Andy Patterson [this message]
2018-10-05 8:28 ` Pierre Neidhardt
2018-10-05 11:44 ` Ricardo Wurmus
2018-10-05 13:30 ` Pierre Neidhardt
2018-10-10 5:54 ` Andy Patterson
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=20181005005652.29b18650@mailservices.uwaterloo.ca \
--to=ajpatter@uwaterloo.ca \
--cc=32770@debbugs.gnu.org \
--cc=mail@ambrevar.xyz \
/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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.