Hi,
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
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/.
I can only find configuration files in manual and am not sure about the usage of other APIs. An pseudo-code example would be very helpful.
P.S.
I was doing (setf asdf::*user-cache* ...) and it worked fine in 2.009, but it seems not working in 2.010.
On 12/5/10 Dec 5 -9:15 PM, Jianshi Huang wrote:
Hi,
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
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/.
I can only find configuration files in manual and am not sure about the usage of other APIs. An pseudo-code example would be very helpful.
P.S.
I was doing (setf asdf::*user-cache* ...) and it worked fine in 2.009, but it seems not working in 2.010.
Have you tried enabling ASDF-BINARY-LOCATIONS-COMPATIBILITY, without CENTRALIZE-BINARIES?
Please have a look again at the manual for this function and see if it meets your needs.
Faré may have a different solution based on the DSL. I suspect that something involving :HOME will do the trick --- if you use SBCL, at least, I don't think you want ALL the fasl files relocated; some should stay in /usr/lib...
Also, if you can, please let us know why this didn't emerge from the manual as a possible solution. I'd like to enhance the manual if there's something obvious to be done.
Best, r
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=d5637f...
On 6 December 2010 09:25, Robert Goldman rpgoldman@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.
Sorry for a slow reply, I was working on other things.
I was doing (setf asdf::*user-cache* ...) and it worked fine in 2.009, but it seems not working in 2.010.
I don't remember changing anything about it. Can you show me how to reproduce the bug?
rpg answered:
Have you tried enabling ASDF-BINARY-LOCATIONS-COMPATIBILITY, without CENTRALIZE-BINARIES?
Yup, should work.
Please have a look again at the manual for this function and see if it meets your needs.
Faré may have a different solution based on the DSL. I suspect that something involving :HOME will do the trick --- if you use SBCL, at least, I don't think you want ALL the fasl files relocated; some should stay in /usr/lib...
See my solution above. wrapping-output-translations already does the right thing to protect SBCL's contrib FASLs safe. Also, mind how (setf output-translations) STABLE-SORTs the source patterns by decreasing length so that a more-specific pattern should always have precedence over a less-specific pattern. These two features should redundantly ensure contribs are safe.
Also, if you can, please let us know why this didn't emerge from the manual as a possible solution. I'd like to enhance the manual if there's something obvious to be done.
See my manual change.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." — Isaac Asimov
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=d5637f...
On 6 December 2010 09:25, Robert Goldman rpgoldman@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
-
Faré -
Jianshi Huang -
Robert Goldman