![](https://secure.gravatar.com/avatar/4ad57009bcdf1ac3818ce190dacffc6b.jpg?s=120&d=mm&r=g)
On Sat, Mar 13, 2010 at 4:40 PM, Faré <fahree@gmail.com> wrote:
It's also what I committed to 1.634.
Thanks for your explanations and corrections. I just updated ECL to use 1.634. FYI, the reason why I did not add **/*.* is because the sbcl case was just specified like that: (getenv "SBCL_HOME"), which is what I more or less adapted. Someone should have a look at that, because asdf might be broken for sbcl.
PS: if you're going to have some magic ECL-provided ASDF systems that are tied to the implementation, you should probably want to:
The ASDF systems I provide are tied to the implementation in that they come pre-built and require that particular version but should not overwrite whatever the user provides: they include asdf, sb-profile, clx, sockets, etc, and I would not feel very comfortable imposing our choice of tools when there might be newer versions out there.
C- if you want to bundle systems that are not too tied to ECL internals, you may want to add to default-source-registry something like: #+ecl (:tree ,(translate-logical-pathname "SYS:bundled-systems;")) There is no problem with providing asdf.asd there, though it's probably redundant with the magic from (require :asdf).
It may be redundant but I would like to see ECL's own asdf path somehow hardcoded in asdf.lisp, not as a main search place but as an always there option. The reason is that we already had a couple of cases in which people overwrote ASDF's search path, resulting in ECL being unable to locate any of its default tools when ASDF:LOAD-OP'ed. Thanks again for your help. Using the latest changes in ASDF ECL is now capable of building and shipping its own versions of CLX and other tools in a way that can then be linked to other FASL, programs or shared libraries using the ASDF extensions we already had. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com