Currently, ASDF ignores all file types supplied by the user when specifying a :PATHNAME value for a component. This did not happen before, though.
This is kind of annoying and hard to deal with, due to ECL's need of prebuilt ASDF files -- these are ASDF components that contain files with precompile sources, whose file extension need not coincide with the one being used by ASDF at the time.
For instance, ECL may be launched with the bytecodes compiler as default (file extension is ".fasc"), but require to load sockets.asd, which contains the precompiled binary file sockets.fas, as in
(DEFSYSTEM "sockets" :CLASS ASDF::PREBUILT-SYSTEM :LIB #P"SYS:LIBSOCKETS.A" :DEPENDS-ON NIL :COMPONENTS ((:COMPILED-FILE "sockets" :PATHNAME #P"SYS:SOCKETS.FAS")))
What would be the appropriate fix for this?
Juanjo
On Sun, Oct 28, 2012 at 6:41 AM, Juan Jose Garcia-Ripoll juanjose.garciaripoll@gmail.com wrote:
Currently, ASDF ignores all file types supplied by the user when specifying a :PATHNAME value for a component. This did not happen before, though.
No, it doesn't. If you pass a #p"..." pathname, then whatever you specify is used untouched. If you pass a string, then the declared type (if any) is used with it.
This behavior has worked for ever with ASDF 2. (ASDF 1 wasn't behaving portably in the corner cases.)
This is kind of annoying and hard to deal with, due to ECL's need of prebuilt ASDF files -- these are ASDF components that contain files with precompile sources, whose file extension need not coincide with the one being used by ASDF at the time.
For instance, ECL may be launched with the bytecodes compiler as default (file extension is ".fasc"), but require to load sockets.asd, which contains the precompiled binary file sockets.fas, as in
(DEFSYSTEM "sockets" :CLASS ASDF::PREBUILT-SYSTEM :LIB #P"SYS:LIBSOCKETS.A" :DEPENDS-ON NIL :COMPONENTS ((:COMPILED-FILE "sockets" :PATHNAME #P"SYS:SOCKETS.FAS")))
What would be the appropriate fix for this?
Can you give me a script that reproduces the failure?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org ``gode'' in French (pronounce as ``god'' in English) means a dildo; the latin word for god is ``deus'', which pronounces like the tennis scoring term ``deuce'' in English. How can anyone see anything intrinsically holy in words? — Faré
On Sun, Oct 28, 2012 at 12:59 AM, Faré fahree@gmail.com wrote:
On Sun, Oct 28, 2012 at 6:41 AM, Juan Jose Garcia-Ripoll juanjose.garciaripoll@gmail.com wrote:
Currently, ASDF ignores all file types supplied by the user when
specifying
a :PATHNAME value for a component. This did not happen before, though.
No, it doesn't. If you pass a #p"..." pathname, then whatever you specify is used untouched. If you pass a string, then the declared type (if any) is used with it.
I did not mean that it touches the relative pathname, but the fact is that ASDF does not use the path which is passed. Instead, at various parts, this path is translated into an absolute path and that involves changing the type of the relative path.
This behavior has worked for ever with ASDF 2. (ASDF 1 wasn't behaving portably in the corner cases.)
As I said, something must have changed w.r.t. to relatives paths between asdf(old)+asdf-ecl and asdf(new)+asdf-bundle, because the lines below used to work
(ext::install-bytecodes-compiler) (setf *load-verbose* t) (require :asdf) (load "~/quicklisp/setup")
Juanjo
I did not mean that it touches the relative pathname, but the fact is that ASDF does not use the path which is passed. Instead, at various parts, this path is translated into an absolute path and that involves changing the type of the relative path.
Can you give a reproducible example?
As I said, something must have changed w.r.t. to relatives paths between asdf(old)+asdf-ecl and asdf(new)+asdf-bundle, because the lines below used to work
(ext::install-bytecodes-compiler) (setf *load-verbose* t) (require :asdf) (load "~/quicklisp/setup")
This particular example looks like it works for me on ecl-12.7.1-52ca46e0-linux-x64. So does replacing the (require :asdf) by loading 2.25.4. On the other hand, (asdf:upgrade-asdf) from the builtin 2.017.5 miserably segfaults :-(
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities. Truth isn't. — Mark Twain
On Sun, Oct 28, 2012 at 1:51 AM, Faré fahree@gmail.com wrote:
This particular example looks like it works for me on ecl-12.7.1-52ca46e0-linux-x64. So does replacing the (require :asdf) by loading 2.25.4. On the other hand, (asdf:upgrade-asdf) from the builtin 2.017.5 miserably segfaults :-(
The version released with that ECL is too old. Recent git sources ship with the latest ASDF and asdf-bundle (well, perhaps a few days off if I missed some announcement)
If you load 2.25.4 on that release, it will not use the prebuilt asdf but rather just load the *.fas files, which misses totally the point: prebuilt components do not work.
If you want to reproduce the error and see how component-relative-pathname fails to produce the right output, use this
(ext::install-bytecodes-compiler) (setf *load-verbose* t) (progn (load "~/devel/ecl/contrib/asdf/asdf.lisp" :verbose t) (load "~/devel/ecl/contrib/asdf/specials.lisp" :verbose t) (load "~/devel/ecl/contrib/asdf/bundle.lisp" :verbose t) (load "~/devel/ecl/contrib/asdf/ecl.lisp" :verbose t)) (trace asdf::component-relative-pathname) (load "~/quicklisp/setup")
The definition of component-relative-pathname wraps around the slot value, totally ignoring the value of the pathname type
(defmethod component-relative-pathname ((component component)) (coerce-pathname (or (slot-value component 'relative-pathname) (component-name component)) :type (source-file-type component (component-system component)) :defaults (component-parent-pathname component)))
Thus the screwed output:
1> (COMPONENT-RELATIVE-PATHNAME #<compiled-file "sockets" "sockets">) <1 (COMPONENT-RELATIVE-PATHNAME #P"SYS:SOCKETS.FASC") 1> (COMPONENT-RELATIVE-PATHNAME #<compiled-file "sockets" "sockets">) <1 (COMPONENT-RELATIVE-PATHNAME #P"SYS:SOCKETS.FASC")
Juanjo
-
Faré -
Juan Jose Garcia-Ripoll