[asdf-devel] asdf output locations

[Robert Goldman]

On 2/1/10 Feb 1 -9:48 AM, Faré wrote:
> On 1 February 2010 10:34, Robert Goldman <rpgoldman at 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