Hi!
I have been mainly using CLISP on Win32 for a while now. I have set
up ASDF (not ASDF-install though) as my packaging system and it works
quite nicely.
Having used SBCL before on Linux, I am just getting around to
installing SBCL on Win32. I am pondering a potential issue. By my
logic, since I used CLISP on my Win32 box, the ASDF end up having the
system compile .FAS files that are CLISP specific (as denoted by the
hyperspec as "implementation-specific"). So, if I installed SBCL and
the point its ASDF registry to overlay on the my existing ASDF
registry for CLISP, I am thinking that I am going to encounter
problems. I have not tried anything yet, but I am thinking that the
FAS files will not load. I want to just be prepared for the
inevidible. Therefore, to my questions:
Is my assumption wrong?
If not, what is good strategy for managing this situation? I prefer
*not* to maintain *two* registries. I am open to go straight to SBCL
exclusively, but the port of SBCL on Win32 is still in progress, so
that may lead to other issues. Hey, maybe someone can get me a vote of
confidence on that subject.
Thanks in advance,
Ralph
--
Ralph Allan Rice
ralph.rice (at) gmail.com
http://coderz.blogspot.com
Ralph Allan Rice wrote:
> If not, what is good strategy for managing this situation? I prefer
> *not* to maintain *two* registries. I am open to go straight to SBCL
> exclusively, but the port of SBCL on Win32 is still in progress, so
> that may lead to other issues. Hey, maybe someone can get me a vote of
> confidence on that subject.
There is a project for managing multiple FASL locations, one for each CL
implementation:
http://common-lisp.net/project/cl-containers/asdf-binary-locations/
but I haven't tried it so YMMV.
mfh
On Jun 25, 9:11 am, Mark Hoemmen <············@gmail.com> wrote:
> There is a project for managing multiple FASL locations, one for
> each CL implementation:
>
> http://common-lisp.net/project/cl-containers/asdf-binary-locations/
>
> but I haven't tried it so YMMV.
This is working really well for me.
Basically, first you specify a root folder where the fasl files are to
be written, and then every .fasl file generated by ASDF will be put in
a directory of the form:
root/compiler-name-version-os-arch/path/to/file/foo.fasl
This setup avoids clashes between different compilers, between
different versions of the same compiler, and even between different
modes (ANSI/Modern) in Allegro.
As a result, the source code directories are not cluttered with fasl
files. Only those created using compile-file outside ASDF will be
placed there.
A downside might be that fasl files will not be removed if you remove
the corresponding lisp source files or directories. If you think of
this as a problem, just manually delete the root folder every now and
then. ASDF will happily regenerate whatever it needs, by (system)
definition!
- Willem
On Jun 25, 6:17 am, Willem Broekema <········@gmail.com> wrote:
> On Jun 25, 9:11 am, Mark Hoemmen <············@gmail.com> wrote:
>
> > There is a project for managing multiple FASL locations, one for
> > each CL implementation:
>
> >http://common-lisp.net/project/cl-containers/asdf-binary-locations/
>
> > but I haven't tried it so YMMV.
>
> This is working really well for me.
>
> Basically, first you specify a root folder where the fasl files are to
> be written, and then every .fasl file generated by ASDF will be put in
> a directory of the form:
>
> root/compiler-name-version-os-arch/path/to/file/foo.fasl
>
> This setup avoids clashes between different compilers, between
> different versions of the same compiler, and even between different
> modes (ANSI/Modern) in Allegro.
>
> As a result, the source code directories are not cluttered with fasl
> files. Only those created using compile-file outside ASDF will be
> placed there.
>
> A downside might be that fasl files will not be removed if you remove
> the corresponding lisp source files or directories. If you think of
> this as a problem, just manually delete the root folder every now and
> then. ASDF will happily regenerate whatever it needs, by (system)
> definition!
>
> - Willem
This sounds like a great option. Thanks for the info!
--
Ralph
On Mon, 25 Jun 2007 05:17:24 -0000, Ralph Allan Rice <··········@gmail.com>
tried to confuse everyone with this message:
>Hi!
>
>I have been mainly using CLISP on Win32 for a while now. I have set
>up ASDF (not ASDF-install though) as my packaging system and it works
>quite nicely.
>
>Having used SBCL before on Linux, I am just getting around to
>installing SBCL on Win32. I am pondering a potential issue. By my
>logic, since I used CLISP on my Win32 box, the ASDF end up having the
>system compile .FAS files that are CLISP specific (as denoted by the
>hyperspec as "implementation-specific"). So, if I installed SBCL and
>the point its ASDF registry to overlay on the my existing ASDF
>registry for CLISP, I am thinking that I am going to encounter
>problems. I have not tried anything yet, but I am thinking that the
>FAS files will not load. I want to just be prepared for the
>inevidible. Therefore, to my questions:
>
>Is my assumption wrong?
>
Yes, it is. SBCL uses .fasl files, so it won't bother loading CLISP's
.fas files.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Ralph Allan Rice <··········@gmail.com> writes:
> Having used SBCL before on Linux, I am just getting around to
> installing SBCL on Win32. I am pondering a potential issue. By my
> logic, since I used CLISP on my Win32 box, the ASDF end up having the
> system compile .FAS files that are CLISP specific (as denoted by the
> hyperspec as "implementation-specific"). So, if I installed SBCL and
> the point its ASDF registry to overlay on the my existing ASDF
> registry for CLISP, I am thinking that I am going to encounter
> problems. I have not tried anything yet, but I am thinking that the
> FAS files will not load. I want to just be prepared for the
> inevidible. Therefore, to my questions:
Another option, and one that we have used with DEFSYSTEM and our own
files is to use logical pathnames and introduce our own scheme for
naming the binary directory. The directories is then specified as beingz
something like:
SYSNAME:SRC;
SYSNAME:BIN;
and then a translations.lisp file is used, with appropriate #+
statements to enable the appropriate translation from the BIN; directory
to a specialized one depending on the lisp implementation.
--
Thomas A. Russ, USC/Information Sciences Institute