Note that with ABL, you must carefully load ABL and set whichever variable in each Lisp startup script, so the amount of work is no less.
I don't see this --- all I do is load it and I'm done, and it's not so carefully, either. It's just a one-liner. Your experience of A-B-L and mine seem radically different in ways I can't account for. Feel like I'm missing something here....
I suppose this redirection might be enabled in ABL by default when you're using the separate ABL, but ABL is disabled by default when using the current ASDF, for obvious reasons of backward compatibility. And so you currently need to explicitly enable the builtin ABL where you used to load an external ABL. In either case, that's a one-liner to be inserted early in your Lisp startup, between (require :asdf) and the first time asdf is used. Annoying stuff suitable only to turn newbies away.
Once I replace the builtin ABL by AOL, the configuration will still be a single line, but for the whole user or machine, instead of each and every Lisp startup script. Or you can continue to do it in a startup script with a one liner, if you want. The line will have changed, but it'll be documented and if you're doing that, you're an expert anyway. Something like (asdf:ensure-output-locations '(:asdf-output-locations :enable-user-cache))
Contrariwise, I don't see how the above does what I am doing now -- it looks like that redirection line (/my/special/cache) will only work on one system's files, rather than pervasively as A-B-L does.
You can redirect "/" or :root: ("/" (:home ".fasl" :implementation)) (:root ("/var/cache/common-lisp" :uid :implementation-type)) Actually, I'd like to have a keyword for :uid and/or :user, but I don't know how to portably (across OS and implementation) extract the uid or username or whatelse, and I'm not sure I want to add such machinery to asdf. But I'll accept one if contributed.
Do we get the behavior of asdf-binary-locations by doing
(:asdf-output-locations (:map "*" :implementation))
? This seems forbidden by the grammar.
We can simplify the common case in the API, so I propose :enable-user-cache no paren, no nothing, be how you enable ABL-style global fasl redirection.
echo "(:asdf-output-locations :enable-user-cache)" > ~/.config/common-lisp/asdf-output-locations.conf
I'm concerned that the above notation only provides mappings for absolute components (since the start of a directory-designator must be an /absolute/ component designator. Here's why: I often find myself working with Lispers who are not sophisticated about ASDF (or even very sympathetic towards it). For working with them we typically provide a top-level checkout from the version control system which will contain a file that will, when loaded, populate their *central-registry*, using some magic applied to *load-truename*. Would that be relatively straightforward here? Should we add :this-directory to the set of absolute-component-designators?
I could trivially add :current-directory -- but understand the risks if you mix and match absolute and relative. Maybe I should recognize specially :current-directory as a relative directory component, too.
I could add that to the source-registry mini-language, too.
Are logical pathnames permitted in a directory-designator?
Yes, but they will be truename'd on the source side, because ASDF truenames its .asd files to locate source code. On the destination side is where you can and want to do funky mappings, anyway.
E.g., write C object files to a specific location, dump parenscript preprocessing outputs (javascript files) into a directory from which they will be served by the web server, etc.
That's tricky. How do you currently do that with ABL?
I don't --- I write my own OUTPUT-FILES method in a .asd file that's a crawling horror involving caching the value of *load-truename* into a global and doing pathname-wrangling.
Gah! Well, if you have any bright idea, I'm all ears. I suppose you can use logical pathnames (cough, cough) as destination mappings for AOL, but oh my.
In the spirit of ASDF, we should be writing output-files methods and then allowing your code to shuffle them, but that use-case seems to break down a bit here.
Consider providing an asdf system definition for a web site. You want to specify the relative location of the content files, which may be generated by asdf operations (e.g., my parenscript example). Those content files must be findable by the code in your system. So this seems like a case where the "let the end user decide where to put the output files" breaks down.... Hm. Needs more thought. These web content files are a case where the code/data distinction is not so clear, and ASDF has not handled data files well (indeed, by unpredictably relocating code files, it has broken our ability to find data files using *load-truename*).
I don't have a clear solution for that problem at this point. If anyone has one, I'm curious.
ASDF has no notion of "installed file".
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I know that most men, including those at ease with problems of the greatest complexity, can seldom accept even the simplest and most obvious truth if it be such as would oblige them to admit the falsity of conclusions which they have delighted in explaining to colleagues, which they have proudly taught to others, and which they have woven, thread by thread, into the fabric of their lives. — Tolstoy