From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Patterson Subject: bug#32770: Packaging SLIME/SWANK as Common Lisp library Date: Fri, 5 Oct 2018 00:56:52 -0400 Message-ID: <20181005005652.29b18650@mailservices.uwaterloo.ca> References: <87museeyy5.fsf@ambrevar.xyz> <20180929151630.00cf6396@mailservices.uwaterloo.ca> <87lg7iwu9i.fsf@ambrevar.xyz> <87k1n2wten.fsf@ambrevar.xyz> <20181002045531.78223c72@mailservices.uwaterloo.ca> <878t3gwsrm.fsf@ambrevar.xyz> <20181003012224.5baff3ac@mailservices.uwaterloo.ca> <8736tmj2vj.fsf@ambrevar.xyz> <20181004010308.7825505f@mailservices.uwaterloo.ca> <87k1mym7kb.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44989) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g8IRn-0007jG-NN for bug-guix@gnu.org; Fri, 05 Oct 2018 01:14:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g8IBf-0003WD-Th for bug-guix@gnu.org; Fri, 05 Oct 2018 00:58:09 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:33049) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g8IBe-0003TM-JH for bug-guix@gnu.org; Fri, 05 Oct 2018 00:58:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g8IBe-0006Dd-8H for bug-guix@gnu.org; Fri, 05 Oct 2018 00:58:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87k1mym7kb.fsf@ambrevar.xyz> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Pierre Neidhardt Cc: 32770@debbugs.gnu.org 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 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))))