all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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))))

  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.