ASDF 2
(Probably only of interest to patrickwonders, who is undoubtedly ahead of me... ;-)
So, it's been a month now that I've been using ASDF 2. To be honest, I also switched from SBCL to LispWorks as my primary platform at the same time (I still run them both). I say that only in "full disclosure", I don't think one colored my impression of the other at all.
Overall, I like ASDF 2. And it's for just one main reason, really. I mean, there are nice little differences, like the adoption of the $HOME/.config tree for initialization. Elvis knows, we needed that. But the number one thing I love about it: a fully implemented and documented mechanism for relocating object files based on their sources.
Why is this a big deal?
When you're running a lisp system out of your account, sometimes you want object files to appear near their sources. This is typical of software you're developing. For example, if you're working on foo/bar/baz.lisp you'd like the object file to be obvious: foo/bar/baz.fasl
Other times, you want the object files to be squirreled away in a separate tree, often including architecture and platform and system names in the paths. This is typical of libraries you're using but not developing. E.g., you'd like foo/bar/baz.lisp to compile into $HOME/.common-lisp/cache/sbcl-1.0.35-x86-64/foo/bar/baz.fasl.
This isn't an unusual idea, to be sure; it's very similar (although with some key differences) to the way that many projects have Makefiles with configurable object hierarchies, DESTDIR and prefix hacks, and so on. What's really nice about ASDF 2's implementation, though, is that it's automatically available to all ASDF projects (so you define it in just one place, and it's inherited by all your projects). No per directory tweaks, no configure scripts, no environment variables...
For example, here's my first output translations file. All it does is map anything under my ~/src tree into local directories, and leaves the rest in the default implementation-specific tree.
: rtfm; cat .config/common-lisp/asdf-output/translations.conf
(:output-translations
;; If it's located in ~/src, it's something we're developing, which means lots
;; of SLIME based development. So, look for and store FASL files in the same
;; place that SLIME uses.
(#p"/home/krz/src/**/*.*" t)
;; Yeah, that's all. Just do the normal thing from here on out.
:inherit-configuration)
So, why is this a big win? Because ASDF and SLIME are independent of each other. By configuring ASDF to match SLIME's expectations, you can now compile into and share the same trees, regardless of whether you compiled any given file interactively with SLIME or batch-stye with ASDF. They'll find each other's files.
By comparison, things outside the ~/src tree are filed in a different place, unique to each lisp implementation and architecture. In this way, the same source tree can be compiled, from just one tree, into multiple destinations, and no one ever gets in the way with each other.
Seriously, this made my life a lot simpler than it was under ASDF 1, and I'm very grateful for it.
So, it's been a month now that I've been using ASDF 2. To be honest, I also switched from SBCL to LispWorks as my primary platform at the same time (I still run them both). I say that only in "full disclosure", I don't think one colored my impression of the other at all.
Overall, I like ASDF 2. And it's for just one main reason, really. I mean, there are nice little differences, like the adoption of the $HOME/.config tree for initialization. Elvis knows, we needed that. But the number one thing I love about it: a fully implemented and documented mechanism for relocating object files based on their sources.
Why is this a big deal?
When you're running a lisp system out of your account, sometimes you want object files to appear near their sources. This is typical of software you're developing. For example, if you're working on foo/bar/baz.lisp you'd like the object file to be obvious: foo/bar/baz.fasl
Other times, you want the object files to be squirreled away in a separate tree, often including architecture and platform and system names in the paths. This is typical of libraries you're using but not developing. E.g., you'd like foo/bar/baz.lisp to compile into $HOME/.common-lisp/cache/sbcl-1.0.35-x86-64/foo/bar/baz.fasl.
This isn't an unusual idea, to be sure; it's very similar (although with some key differences) to the way that many projects have Makefiles with configurable object hierarchies, DESTDIR and prefix hacks, and so on. What's really nice about ASDF 2's implementation, though, is that it's automatically available to all ASDF projects (so you define it in just one place, and it's inherited by all your projects). No per directory tweaks, no configure scripts, no environment variables...
For example, here's my first output translations file. All it does is map anything under my ~/src tree into local directories, and leaves the rest in the default implementation-specific tree.
: rtfm; cat .config/common-lisp/asdf-output/translations.conf
(:output-translations
;; If it's located in ~/src, it's something we're developing, which means lots
;; of SLIME based development. So, look for and store FASL files in the same
;; place that SLIME uses.
(#p"/home/krz/src/**/*.*" t)
;; Yeah, that's all. Just do the normal thing from here on out.
:inherit-configuration)
So, why is this a big win? Because ASDF and SLIME are independent of each other. By configuring ASDF to match SLIME's expectations, you can now compile into and share the same trees, regardless of whether you compiled any given file interactively with SLIME or batch-stye with ASDF. They'll find each other's files.
By comparison, things outside the ~/src tree are filed in a different place, unique to each lisp implementation and architecture. In this way, the same source tree can be compiled, from just one tree, into multiple destinations, and no one ever gets in the way with each other.
Seriously, this made my life a lot simpler than it was under ASDF 1, and I'm very grateful for it.