On 2/1/10 Feb 1 -9:48 AM, Faré wrote:
On 1 February 2010 10:34, Robert Goldman rpgoldman@sift.info wrote:
Having the documentation here is helpful, but a few examples would be even more helpful.
For example, if I wanted to replicate Gary's A-B-L in the new configuration language, how would I do that? I don't see an opportunity in the language to grab info about the lisp implementation and compute a binary pathname. Is it possible to perform arbitrary computations in the configuration file? *features* is not enough to do what Gary does.
mkdir ~/.config/common-lisp/asdf-output-locations.conf.d/ echo '(:root :user-cache)' > ~/.config/common-lisp/asdf-output-locations.conf.d/00-user-cache echo '("/my/special/path" ("/my/special/cache" :implementation "gratuitous/subdirs"))' > ~/.config/common-lisp/asdf-output-locations.conf.d/10-special
Examples ought indeed to be in the final documentation.
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....
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.
Do we get the behavior of asdf-binary-locations by doing
(:asdf-output-locations (:map "*" :implementation))
? This seems forbidden by the grammar.
My concern is that I don't see how to get the one-liner pervasive behavior of A-B-L yet.
Once I see that, I suspect I'll try to provide backward-compatible behavior by providing a one-liner....
A couple of related questions:
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?
Are logical pathnames permitted in a directory-designator?
Also, one obvious extension to the existing A-B-L would be to direct different kinds of components to write the outputs of their various operations into different places. Is that possible with this framework?
I suppose you could use logical pathnames on the destination side of your translations. Configuring logical pathnames is out of the scope of AOL. But the docs should suggest the idea. logical pathnames are also a cthulhuesque piece of non-portability horror.
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.
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*).
best, r