From: Edi W. <ed...@ag...> - 2003-09-22 09:48:01
|
[Is this the right mailing list for ASDF-INSTALL? I hope so.] Hi! I've made my packages CL-PPCRE, CL-WHO, and HTML-TEMPLATE asdf-installable because, well, mostly because it was really easy. I just had to edit the CLiki page and provide a PGP signature. 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? What would be the best way to do it? 1. I suppose it is possible to let ASDF take care of compiling the glue stuff[1]. I don't know how to do this but I think I can figure that out - maybe by looking at the CL-SQL sources. I wouldn't mind if someone provides an example, though... :) 2. CL-GD needs UFFI. How does ASDF-INSTALL cope with this? 3. Of course, there's still a lot that can go wrong - the user is on Solaris and doesn't have gcc, the user doesn't have libgd installed, the user does have libgd but hasn't installed, say, libfreetype, and so one. I suppose all of these will be caught at compile time, so maybe it's OK to just let the user run into this situation? 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? Any thoughts? Cheers, Edi. [1] <http://weitz.de/cl-gd/#install> |
From: Nikodemus S. <tsi...@cc...> - 2003-09-22 10:37:54
|
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 |
From: Edi W. <ed...@ag...> - 2003-09-22 11:08:24
|
On Mon, 22 Sep 2003 13:37:29 +0300 (EEST), Nikodemus Siivola <tsi...@cc...> 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. |
From: Daniel B. <da...@te...> - 2003-09-22 12:41:11
|
Edi Weitz <ed...@ag...> writes: > On Mon, 22 Sep 2003 13:37:29 +0300 (EEST), Nikodemus Siivola <tsiivola@cc= .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 |
From: Kevin R. <ke...@ro...> - 2003-09-22 16:07:55
|
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 ke...@ro... |
From: Kevin R. <ke...@ro...> - 2003-09-22 16:21:36
|
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 ke...@ro... |