Hi!
I have a file swank-stuff.lisp that uses swank if available, with forms such as:
#+swank (in-package :swank) #+swank …
It contains also definitions that are alway available.
If I define it as:
(:file "swank-stuff" :depends-on ("other-stuff"))
and compile it when I have swank, it produces a .fasl that contains a toplevel (in-pacakge :swank). Therefore when I load the system in an image without swank, it produces this error:
; Loading "com.informatimago.lse.unix-cli" . > Error: There is no package named "SWANK" . > While executing: ccl::set-package, in process listener(1).
I tried to define it as:
(:file "swank-stuff" :depends-on ("other-stuff") :in-order-to ((asdf:load-op (asdf:compile-op "swank-stuff"))))
but it still doesn't work. Is there a way to make it so that swank-stuff is always loaded/compiled from source, instead of from the .fasl file?
On 3/15/12 Mar 15 -9:05 PM, Pascal J. Bourguignon wrote:
Hi!
I have a file swank-stuff.lisp that uses swank if available, with forms such as:
#+swank (in-package :swank) #+swank …
It contains also definitions that are alway available.
If I define it as:
(:file "swank-stuff" :depends-on ("other-stuff"))
and compile it when I have swank, it produces a .fasl that contains a toplevel (in-pacakge :swank). Therefore when I load the system in an image without swank, it produces this error:
; Loading "com.informatimago.lse.unix-cli" . > Error: There is no package named "SWANK" . > While executing: ccl::set-package, in process listener(1).
I tried to define it as:
(:file "swank-stuff" :depends-on ("other-stuff") :in-order-to ((asdf:load-op (asdf:compile-op "swank-stuff"))))
but it still doesn't work. Is there a way to make it so that swank-stuff is always loaded/compiled from source, instead of from the .fasl file?
Sorry, why should that definition fix the problem? I.e., what is it about compiling the file from source that ensures that swank will be loaded, when loading the FASL doesn't?
At any rate, there IS a way to ensure that swank-stuff is always loaded from lisp instead of from fasl --- it's been discussed in the developers' list in the past.
I /thought/ this was a FAQ, or had been rolled into ASDF proper, but I don't see anything. That's regrettable, since this is something that I have seen (partially) implemented over and over.
Best, r
Robert Goldman rpgoldman@sift.info writes:
On 3/15/12 Mar 15 -9:05 PM, Pascal J. Bourguignon wrote:
Hi!
I have a file swank-stuff.lisp that uses swank if available, with forms such as:
#+swank (in-package :swank) #+swank …
It contains also definitions that are alway available.
If I define it as:
(:file "swank-stuff" :depends-on ("other-stuff"))
and compile it when I have swank, it produces a .fasl that contains a toplevel (in-pacakge :swank). Therefore when I load the system in an image without swank, it produces this error:
; Loading "com.informatimago.lse.unix-cli" . > Error: There is no package named "SWANK" . > While executing: ccl::set-package, in process listener(1).
I tried to define it as:
(:file "swank-stuff" :depends-on ("other-stuff") :in-order-to ((asdf:load-op (asdf:compile-op "swank-stuff"))))
but it still doesn't work. Is there a way to make it so that swank-stuff is always loaded/compiled from source, instead of from the .fasl file?
Sorry, why should that definition fix the problem? I.e., what is it about compiling the file from source that ensures that swank will be loaded, when loading the FASL doesn't?
The #+swank in the source file.
At any rate, there IS a way to ensure that swank-stuff is always loaded from lisp instead of from fasl --- it's been discussed in the developers' list in the past.
I /thought/ this was a FAQ, or had been rolled into ASDF proper, but I don't see anything. That's regrettable, since this is something that I have seen (partially) implemented over and over.
Didn't see anything about it in the ASDF Manual.
"Pascal J. Bourguignon" pjb@informatimago.com writes:
Sorry, why should that definition fix the problem? I.e., what is it about compiling the file from source that ensures that swank will be loaded, when loading the FASL doesn't?
The #+swank in the source file.
I mean, I expect the #+swank in the source file to disable the dependency on swank when it is not present.
Notice that using #+swank (:file "swank-stuff") in the ASD file, works to disable loading swank-stuff, but since now I have to put #+swank (call-swank-stuff) in the other files, I still have the same problem: I need to erase the fasl in .cache/common-lisp and recompile everything when I need to switch between swank and non-swank targets.
Dear Pascal,
sorry for a slow reply.
If you want something to only load from source, you'll have to do something like:
(defclass asdf::uncompiled-cl-source-file (cl-source-file) ()) (defmethod perform-op ((op load-op) (c asdf::uncompiled-cl-source-file)) (perform-op (make-instance 'load-source-op) c)) (defmethod perform-op ((op compile-op) (c asdf::uncompiled-cl-source-file)) (values)) (defmethod output-files ((op compile-op) (c asdf::uncompiled-cl-source-file)) nil) (defmethod input-files ((op load-op) (c asdf::uncompiled-cl-source-file)) (input-files (make-instance 'load-source-op) c))
You can afterwards have a defsystem form that uses :uncompiled-cl-source-file as your component type.
Wholly untested. Hope this helps.
Now, if your problem is conditional dependency, I believe the whole idea is bunk. I recommend instead that you should use asdf::find-symbol* to detect at runtime whether the dependency is present. Otherwise, you'll have weird results when the dependency is loaded after the conditional thing was evaluated to the negative.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The common argument that crime is caused by poverty is a kind of slander on the poor. — H. L. Mencken
On 3/16/12 Mar 16 -2:20 PM, Faré wrote:
Dear Pascal,
sorry for a slow reply.
If you want something to only load from source, you'll have to do something like:
(defclass asdf::uncompiled-cl-source-file (cl-source-file) ()) (defmethod perform-op ((op load-op) (c asdf::uncompiled-cl-source-file)) (perform-op (make-instance 'load-source-op) c)) (defmethod perform-op ((op compile-op) (c asdf::uncompiled-cl-source-file)) (values)) (defmethod output-files ((op compile-op) (c asdf::uncompiled-cl-source-file)) nil) (defmethod input-files ((op load-op) (c asdf::uncompiled-cl-source-file)) (input-files (make-instance 'load-source-op) c))
You can afterwards have a defsystem form that uses :uncompiled-cl-source-file as your component type.
This is something that is often enough needed that it would be great to see it added to ASDF (in a tested form!). I have seen this done multiple times, and each time sooner or later a bug was encountered -- different bugs for different 70% solutions....
Best, R