[asdf-devel] Store all fasl files in a relative directory to the .asd file

[Robert Goldman]

On 12/7/10 Dec 7 -11:08 PM, Faré wrote:
>>> Could anybody show me what's the recommended approach to make all the
>>> compiled files to be stored in a relative directory, either in .asd
>>> file or by lisp code? I'm using ASDF 2.010
>>>
> I just committed this slight improvement to the documentation.
> The end result is not as easy as I'd like, but I hope it's useful:
> 	http://common-lisp.net/gitweb?p=projects/asdf/asdf.git;a=commitdiff;h=d5637f10878d7d4efc365909008885f8a79e6f13
> 
> On 6 December 2010 09:25, Robert Goldman <rpgoldman at sift.info> wrote:
>>> Say, if I have a project in $HOME/prj/ with prj.asd defined, and all
>>> it's dependencies in $HOME/prj/lib/. When I load the project in sbcl,
>>> I want all the compiled fasl files to be stored under
>>> $HOME/prj/fasl/sbcl/.
> 
> If you put this in your
> ~/.config/common-lisp/asdf-output-translations.conf.d/99-source-subdirectory.conf,
> it should do what you asked:
> 
> #.(let ((wild-subdir (make-pathname :directory '(:relative :wild-inferiors)))
>         (wild-file (make-pathname :name :wild :version :wild :type :wild)))
>    `((:root ,wild-subdir ,wild-file)
>      (:root ,wild-subdir :implementation-type ,wild-file)))
> 
> I just tested it, and it looks like it works :-) However, if you don't
> want to have conflicts between old and new versions when you update an
> implementation, use :implementation instead of :implementation-type.

I thought from what Jianshi first posted, that he just wanted stuff
under his home directory to go.  Is the problem that the second piece of
an output configuration cannot be a relative-component-designator?

I would have thought we would have something like:

(:home (:there :implementation-type))

where :there would be anaphoric and would be bound to any pathname that
matches the first piece....

If we don't have anything like :there, should we add it?  The above does
seem unfortunate, since it requires the poor user to grapple with CL
pathnames, something we've tried to avoid.

ASDF-BINARY-LOCATIONS-COMPATIBILITY seems a lot easier than this....

best,
r