[asdf-devel] asdf output locations

[Faré]

>> 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