3 ms·

Well, if we're doing a generic Common Lisp thread some of you might be interested in buildLisp.nix[0], my project to write a build system for CL in Nix[1]. The

by tazjin 7y ago

Well, if we're doing a generic Common Lisp thread some of you might be interested in buildLisp.nix[0], my project to write a build system for CL in Nix[1]. The idea here is that Nix should be usable for builds at the same abstraction level as Bazel (i.e. individual build targets), while retaining the power of the rest of the ecosystem. Example build "manifest" using buildLisp.nix: https://git.tazj.in/tree/third_party/lisp/alexandria/default.nix https://git.tazj.in/tree/third_party/lisp/alexandria/default... This has a few additional neat benefits, such as making it possible to easily spin up a REPL with the correct Lisp & dependencies loaded from within Emacs[2]. There's also a similar project I did for Go[3] to prove the general viability of the concept. [0]: https://git.tazj.in/tree/nix/buildLisp/ https://git.tazj.in/tree/nix/buildLisp/ [1]: https://nixos.org/nix/ https://nixos.org/nix/ [2]: https://git.tazj.in/tree/tools/emacs-pkgs/nix-util/nix-util.el#n69 https://git.tazj.in/tree/tools/emacs-pkgs/nix-util/nix-util.... [3]: https://git.tazj.in/tree/nix/buildGo/README.md https://git.tazj.in/tree/nix/buildGo/README.md

zelly 7y ago
Neat. I will try this. Check out Guix. It's similar but defines packages in Scheme, which I prefer greatly to the Nix DSL.
- tazjin 7y ago
  I actually prefer the Nix language[0] over Scheme, mostly because I enjoy not having to deal with namespaces (which also has drawbacks) and instead modifying one large expression. [0]: https://github.com/tazjin/nix-1p https://github.com/tazjin/nix-1p
fmakunbound 7y ago
Lisp user here. Scratching my head on this one: What's it build exactly? Why would I use this over, say, Quicklisp? Is this just a Nix thing? Edit: Also, why do you need to specify all the .lisp files in the build(?) file?
- tazjin 7y ago
  > What's it build exactly? For libraries, it builds an output with a concatenated FASL for all inputs (which reference the sources by their exact hash in the Nix store, which means that they will be distributed alongside). For programs, it dumps an executable image (save-lisp-and-die with `:executable t`). For `buildLisp.sbclWith` it creates an SBCL that loads an image pre-loaded with all the dependencies. > Why would I use this over, say, Quicklisp? Quicklisp is one small bit of the puzzle (the distribution of packages using ASDF). Using Nix for the task replaces Quicklisp, ASDF, your distribution package manager used to install your Lisp, your distribution package manager used to install native dependencies of your Lisp code (e.g. cl+ssl with openssl[0]), your deployment tooling and generally your entire software packaging and distribution stack which leaves you with one homogeneous system that is easily composed across language boundaries. > why do you need to specify all the .lisp files in the build(?) file? I modeled this after the way Bazel rules are normally written, where specifying each source file is common. In fact, ASDF does this too. [0]: https://git.tazj.in/tree/third_party/lisp/cl-plus-ssl.nix#n22 https://git.tazj.in/tree/third_party/lisp/cl-plus-ssl.nix#n2...

by tazjin 7y ago

zelly 7y ago

Neat. I will try this. Check out Guix. It's similar but defines packages in Scheme, which I prefer greatly to the Nix DSL.

tazjin 7y ago
I actually prefer the Nix language[0] over Scheme, mostly because I enjoy not having to deal with namespaces (which also has drawbacks) and instead modifying one large expression. [0]: https://github.com/tazjin/nix-1p https://github.com/tazjin/nix-1p

fmakunbound 7y ago

Lisp user here. Scratching my head on this one: What's it build exactly? Why would I use this over, say, Quicklisp? Is this just a Nix thing? Edit: Also, why do you need to specify all the .lisp files in the build(?) file?

tazjin 7y ago
> What's it build exactly? For libraries, it builds an output with a concatenated FASL for all inputs (which reference the sources by their exact hash in the Nix store, which means that they will be distributed alongside). For programs, it dumps an executable image (save-lisp-and-die with `:executable t`). For `buildLisp.sbclWith` it creates an SBCL that loads an image pre-loaded with all the dependencies. > Why would I use this over, say, Quicklisp? Quicklisp is one small bit of the puzzle (the distribution of packages using ASDF). Using Nix for the task replaces Quicklisp, ASDF, your distribution package manager used to install your Lisp, your distribution package manager used to install native dependencies of your Lisp code (e.g. cl+ssl with openssl[0]), your deployment tooling and generally your entire software packaging and distribution stack which leaves you with one homogeneous system that is easily composed across language boundaries. > why do you need to specify all the .lisp files in the build(?) file? I modeled this after the way Bazel rules are normally written, where specifying each source file is common. In fact, ASDF does this too. [0]: https://git.tazj.in/tree/third_party/lisp/cl-plus-ssl.nix#n22 https://git.tazj.in/tree/third_party/lisp/cl-plus-ssl.nix#n2...