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))
how about making that be the default?
it's transparent enough and i don't think anyone will mind not seeing fasls thrashing all their source directories as the default behavior...
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.
imho that's stretching the limits of asdf and output directories...
in hu.dwim.wui we have a special web broker that caches the js compilation results and manages recompilations, last-modified http header. also, some of our js scripts are fixed to the preferred locale order of the request (at js compile time), etc...
if you really want to do that using asdf, then i'd suggest adding a custom my-parenscript-file component class and override the generic method to customize where the output goes (assuming there's such a generic).
and maybe renaming that machinery to asdf-temporary-output to avoid confusion. but here i might be the one stretching the limits... :)