Steel Bank Common Lisp

On Mon, Sep 22, 2003 at 11:47:38AM +0200, Edi Weitz wrote:

> However, CL-GD, my latest little project, relies on the existence of
> external libraries (libgd plus a couple of supporting libraries). It
> also expects the user to compile some glue functions written in C
> before he/she can use it.
>
> Do you think it would make sense to make CL-GD asdf-installable as
> well?

Yes!

> What would be the best way to do it?

That I do not know, but generally systems needing glue-code can easily
be provided with methods to compile and load that code. Linedit is
asdf-installable and does the same, though the case is simpler then
your, as there are no significant linking needs -- see:

 http://common-lisp.net/cgi-bin/viewcvs.cgi/src/linedit.asd?rev=1.12&cvsroot=linedit&content-type=text/vnd.viewcvs-markup

Other systems can be pulled in by giving the system itself a
:depends-on list:

  (defsystem :foo
     :depends-on (:bar)
     :components ...)


Cheers,

 -- Nikodemus

On Mon, 22 Sep 2003 13:37:29 +0300 (EEST), Nikodemus Siivola <tsiivola@...> wrote:

> Other systems can be pulled in by giving the system itself a
> :depends-on list:
> 
>   (defsystem :foo
>      :depends-on (:bar)
>      :components ...)

Yes, I know that. My question was how ASDF-INSTALL handles these
dependencies if the other system is not on my local disk. I think the
interesting part of ASDF-INSTALL is that it can pull software from the
Net if it isn't available locally.

Now, UFFI seems to be asdf-installable, so ASDF-INSTALL might download
and install it automatically. Does it do that?

What if the user trusts my PGP key but not Kevin's?

What if I depend on a Lisp library that is not asdf-installable? I
guess that's not really different from not having libgd installed.

Cheers,
Edi.

Edi Weitz <edi@...> writes:

> On Mon, 22 Sep 2003 13:37:29 +0300 (EEST), Nikodemus Siivola <tsiivola@...=
.hut.fi> wrote:
>
>> Other systems can be pulled in by giving the system itself a
>> :depends-on list:

> Yes, I know that. My question was how ASDF-INSTALL handles these
> dependencies if the other system is not on my local disk. I think the
> interesting part of ASDF-INSTALL is that it can pull software from the
> Net if it isn't available locally.

Yes, it pulls dependencies from the net as well

> Now, UFFI seems to be asdf-installable, so ASDF-INSTALL might download
> and install it automatically. Does it do that?

My quick test here says that it attepts to, but compilation of
uffi-1.3.6/tests/foreign-var.fasl fails with

  Install failed due to error:
    unknown foreign symbol: "cs_to_upper"

I don't know what that's about.

> What if the user trusts my PGP key but not Kevin's?

asdf-install will stop and complains when it finds it needs one of
Kevin's packages, leaving your package untarred but not installed.
Probably it needs to be a bit smarter about error recovery in this case.

> What if I depend on a Lisp library that is not asdf-installable? I
> guess that's not really different from not having libgd installed.

Ditto, yes.


=2Ddan

=2D-=20

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources=20

Daniel Barlow wrote:
> My quick test here says that it attepts to, but compilation of
> uffi-1.3.6/tests/foreign-var.fasl fails with
>   Install failed due to error:
>     unknown foreign symbol: "cs_to_upper"

UFFI's test suite uses several shared libraries that are compiled by
the user with using the `make' program. For Debian, those compiled
libraries are contained and installed by the .deb file. For non-Debian
users, the user needs to invoke `make' to create the shared libraries.

So, at this point, UFFI is asdf-install downloadable it appears, but
not installable.

--=20
Kevin Rosenberg
kevin@...

Edi Weitz wrote:
> 4. This will probably also affect the way how Debian and Gentoo
>    install CL-GD. Is that a problem? Kevin, Matthew, are you reading
>    this?

As I mentioned, the shared library is contained in the .deb file for
Debian. In general, I handle the loading of a shared library with ASDF
by having ASDF load a lisp file whose job it is to load the already
existing shared library.

I suppose such a loader can be modified to first check if the library
does not exist in the standard system locations and in the
*load-pathname* directory. If the library can not be found, then the
"loader" lisp file can actually be a "compiler/link" and invoke shell
programs to first compile and link the shared library. I suspect
storing the shared library in the *load-pathname* directory would be
best in this case.

Currently, different options need to be given to compile on linux,
solaris, darwin, and win32. Currently, those differences are handled
by the Makefiles for my projects. You'd need to embed those
differences in your lisp program. Additionally, since cl-gd runs a
number of different lisp implementations, the lisp program needs to
handle the differences in platform identifiers as specified in
cl:*features*. For SBCL, there's examples of this in
sb-bsd-sockets. As an additional compilication, the amd64 nees a new
gcc option for linux to create 32-bit output.

Kevin

--=20
Kevin Rosenberg
kevin@...