....
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".
Agreed, and this can be a real nuisance if your system carries data along with it.
I thought I would mention this now. If we're reforming file writing, we might want to try to pick off this problem as well.
The web application is a plausible one as is, for example, a graphical app that has image files contained with it.
Using *load-truename* to find such files is, as I mentioned earlier, broken by use of A-B-L or any other code that wrangles the output files of the compile-op.
What I typically do is something unpleasant like this (from memory; possibly slightly inaccurate):
1. In the asdf system definition file, do something like this:
(defparameter cl-user::*<sysname>-root-directory* (merge-pathnames (make-pathname :type :unspecific :name :unspecific) *load-truename*)) ;; use cl-user because you don't have access to the package(s) in the ;; as yet not loaded system...
2. In the loaded files at some point
(with-open-file (str (merge-pathnames "imagefile.png" cl-user::*<sysname>-root-directory*)) ....)
I'd love to see a clean way to avoid this....
Cheers, r