I recently downloaded matlisp. I then built it using the installation
instructions, which end with "make". What makes me confused is that
there are no instructions for installing the package in the
system. Now, as long as I'm standing in the matlisp source directory I
can run cmucl and evaluate "(load "start.lisp") to access the package
from lisp. I, however, don't want to be limited to starting my lisp
interpreter in that directory only.
I suspect this is a more general question from someone new to lisp. In
other languages there is often a library or module system with well
defined places to add new libraries or modules. I have not yet been
able to grasp how this works in Common Lisp. And as for the scenario
above, I would like to separate the files needed for using the package
from the files needed to build it. Right now, under that source
directory there is a lot of source files in Fortran as well as
configuration scripts etc. How is this usually done in CL?
Bj�rn
·······@nada.kth.se (Bj�rn Lindberg) writes:
> I recently downloaded matlisp. I then built it using the installation
> instructions, which end with "make". What makes me confused is that
> there are no instructions for installing the package in the
> system. Now, as long as I'm standing in the matlisp source directory I
> can run cmucl and evaluate "(load "start.lisp") to access the package
> from lisp. I, however, don't want to be limited to starting my lisp
> interpreter in that directory only.
>
> I suspect this is a more general question from someone new to lisp. In
> other languages there is often a library or module system with well
> defined places to add new libraries or modules. I have not yet been
> able to grasp how this works in Common Lisp. And as for the scenario
> above, I would like to separate the files needed for using the package
> from the files needed to build it. Right now, under that source
> directory there is a lot of source files in Fortran as well as
> configuration scripts etc. How is this usually done in CL?
If you look in the toplevel directory of the matlisp sources, you'll
find a file called "blas.system", which is meant for such stuff. It
contains a "system definition", wich is just some lisp code calling
the "defsystem" macro in the "make" package (nicknamed "mk"), which is
provided by the "mk:defsystem" library in the file
"defsystem.lisp". Most Lisp libraries use this library.
A "system definition" tells the library which source files have to be
loaded/compiled to use the system (in the case, matlisp is the
system), the dependencies between them, other required packages, where
to find the files etc. In this way, it is comparable to a Makefile.
The mk:defsystem library can be used to load/compile the systems it
knows about, by using the function OPERATE-ON-SYSTEM (or OOS for
short). For example, you can load matlisp by evaluating
* (mk:oos :blas :load)
and compile it with
* (mk:oos :blas :compile)
Of course, mk:defsystem has to find the system definition somehow. The
easiest way to ensure this is to put the file in one of the
directories listed in the variable mk:*central-registry*. This is
likely to be empty initially, PUSHNEWing stuff in it is best done in
you Lisp's startup file (most likely ~/.cmucl-init.lisp, in your
case). Oh, and mk:defsystem has to be loaded itself of course, so put
an appropriate LOAD in there, too.
If you look at the blas.system file, you'll notice that it uses
logical pathnames:
| (mk:defsystem blas
| :source-pathname "matlisp:blas;"
| ...
That tells mk:defsystem to look for the source files in the directory
"blas" on the logical host "matlisp". AFAIK, setting up appropriate
LOGICAL-PATHNAME-TRANSLATIONs is up to the user. Again, the startup
file would be an appropriate place.
Most libraries' source-pathnames are defined in terms of a logical
host "cl-library", so it might be a good idea to create a directory
for it, say ~/cl-library, and set up LOGICAL-PATHNAME-TRANSLATIONs for
this as well. Also, I have my defsystem.lisp in that directory as
well. So, my cmucl-init.lisp looks something like this (not dealing
with matlisp here):
(setf (logical-pathname-translations "home")
'(("**;*.*.*" "/home/henrik/**/*.*.*"))
(logical-pathname-translations "cl-library")
'(("**;*.*.*" #p"home:cl-library;**;")))
(load #p"cl-library:defsystem")
(pushnew #p"cl-library:" mk:*central-registry*)
See also the Cliki page on mk:defsystem at
<http://www.cliki.net/mk-defsystem>, which has some pointers to more
documentation.
hth
Henrik
Henrik Motakef wrote:
....
> (setf (logical-pathname-translations "home")
> '(("**;*.*.*" "/home/henrik/**/*.*.*"))
> (logical-pathname-translations "cl-library")
> '(("**;*.*.*" #p"home:cl-library;**;")))
>
> (load #p"cl-library:defsystem")
> (pushnew #p"cl-library:" mk:*central-registry*)
The latest versions of MK:DEFSYSTEM have the new function
MK:ADD-REGISTRY-LOCATION <pathname>
So the above can be written as
(mk:add-registry-location #p"cl-library:")
...just to let everybody know that the interface is a little cleaner now.
cheers
--
Marco Antoniotti
Henrik Motakef <··············@web.de> writes:
[about mk:defsystem]
Thank you for the thorough explanation. I can see I have to do some
reading. I have a few questions below.
> If you look in the toplevel directory of the matlisp sources, you'll
> find a file called "blas.system", which is meant for such stuff. It
> contains a "system definition", wich is just some lisp code calling
> the "defsystem" macro in the "make" package (nicknamed "mk"), which is
> provided by the "mk:defsystem" library in the file
> "defsystem.lisp". Most Lisp libraries use this library.
>
> A "system definition" tells the library which source files have to be
> loaded/compiled to use the system (in the case, matlisp is the
> system), the dependencies between them, other required packages, where
> to find the files etc. In this way, it is comparable to a Makefile.
The matlisp source directory also contains "dfftpack.system" and
"lapack.system", but no "matlisp.system". Is the "blas.system" still
the major matlisp defsystem file?
> The mk:defsystem library can be used to load/compile the systems it
> knows about, by using the function OPERATE-ON-SYSTEM (or OOS for
> short). For example, you can load matlisp by evaluating
>
> * (mk:oos :blas :load)
So, assuming the package is in place, with logical pathnames properly
set up, this is the equivalent of a C #include statement or a module
loading statement in some other language?
> If you look at the blas.system file, you'll notice that it uses
> logical pathnames:
>
> | (mk:defsystem blas
> | :source-pathname "matlisp:blas;"
> | ...
>
> That tells mk:defsystem to look for the source files in the directory
> "blas" on the logical host "matlisp". AFAIK, setting up appropriate
> LOGICAL-PATHNAME-TRANSLATIONs is up to the user. Again, the startup
> file would be an appropriate place.
This sounds like it's more trouble than benefit, but I guess there is
some good reason to why this logical pathname indirection is being
used.
> Most libraries' source-pathnames are defined in terms of a logical
> host "cl-library", so it might be a good idea to create a directory
> for it, say ~/cl-library, and set up LOGICAL-PATHNAME-TRANSLATIONs for
> this as well. Also, I have my defsystem.lisp in that directory as
> well. So, my cmucl-init.lisp looks something like this (not dealing
> with matlisp here):
>
>
> (setf (logical-pathname-translations "home")
> '(("**;*.*.*" "/home/henrik/**/*.*.*"))
> (logical-pathname-translations "cl-library")
> '(("**;*.*.*" #p"home:cl-library;**;")))
>
> (load #p"cl-library:defsystem")
> (pushnew #p"cl-library:" mk:*central-registry*)
Ok thanks, I saved your post and I will be looking into the defsystem
documentation.
I find it a bit strange though, that neither clisp or cmucl comes with
this kind of thing set up. One would think that it would be good if
they when installing set everything up so that one would just have to
put third party packages in the right place for everything to work. Are
the commercial lisps better in this regard?
Bj�rn
--
War on Iraq, expected # of killed Civilians:
Iraq 500,000
USA 0
·······@nada.kth.se (Bj�rn Lindberg) writes:
> > * (mk:oos :blas :load)
>
> So, assuming the package is in place, with logical pathnames properly
> set up, this is the equivalent of a C #include statement or a module
> loading statement in some other language?
Basically, yes.
> > That tells mk:defsystem to look for the source files in the directory
> > "blas" on the logical host "matlisp". AFAIK, setting up appropriate
> > LOGICAL-PATHNAME-TRANSLATIONs is up to the user. Again, the startup
> > file would be an appropriate place.
>
> This sounds like it's more trouble than benefit, but I guess there is
> some good reason to why this logical pathname indirection is being
> used.
Well, given that a lot of libraries use the same logical host
(cl-library), it's not that much trouble. Logical pathnames allow you
to do lots of funky stuff, for example storing the binaries for
different lisps in different subdirectories without the sources having
to know about that before. You can set up different pathname
translations for cl-library:**;*.lisp and cl-library:**;*.fasl, for
example.
BTW, there is a defsystem-like library called asdf (see it's Cliki
page), that doesn't depend on pathnames, IIRC. The system definition
stays in the same directory as the sources, with a symlink to it in
the registry. After finding the system definition in the registry,
asdf only has to follow the link to find the sources.
> I find it a bit strange though, that neither clisp or cmucl comes with
> this kind of thing set up. One would think that it would be good if
> they when installing set everything up so that one would just have to
> put third party packages in the right place for everything to work. Are
> the commercial lisps better in this regard?
I guess most Lisps /do/ come with something like that - after all,
they have to implement REQUIRE and PROVIDE somehow. It's just that
/how/ they implement it is not standardized.
For example, CMUCL will look for a file
lib/subsystems/foo-library.FASL (where FASL is platform-dependant, for
example x86f on Intel) in it's installation directory when you
(require 'foo). I'm sure CLisp has something similar.
Regards
Henrik
From: Thomas A. Russ
Subject: Re: How to "install" packages in a central place
Date:
Message-ID: <ymiznotpj67.fsf@sevak.isi.edu>
·······@nada.kth.se (=?iso-8859-1?q?Bj=F6rn?= Lindberg) writes:
>
> I find it a bit strange though, that neither clisp or cmucl comes with
> this kind of thing set up. One would think that it would be good if
> they when installing set everything up so that one would just have to
> put third party packages in the right place for everything to work. Are
> the commercial lisps better in this regard?
This simplicity was one of the motivations behind the REQUIRE and
PROVIDE mechanism in Common Lisp. It was in the original specification,
then it was removed, and later put back in. I'm not sure what the
current feeling is about its use or support. Comments?
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
From: Tim Bradshaw
Subject: Re: How to "install" packages in a central place
Date:
Message-ID: <ey3adgte23y.fsf@cley.com>
* Thomas A Russ wrote:
> This simplicity was one of the motivations behind the REQUIRE and
> PROVIDE mechanism in Common Lisp. It was in the original specification,
> then it was removed, and later put back in. I'm not sure what the
> current feeling is about its use or support. Comments?
I use it. I arrange life so that for a module named ORG.TFEB.FOO.BAR,
something that lives in CLEY-LIB:ORG;TFEB;FOO;BAR;BAR-LOADER will load
it. The logical host could obviously vary - I just chose CLEY-LIB
because no one else is likely to. Given that the module names (and
hence pathnames) we use are pretty much known to be clash-free since
they just rely on DNS, it should be relatively simple to extend some
naming scheme like this to be really global. A modified REQUIRE
(which I think we call REQUIRE-MODULE) can then infer the path from
the module name. I guess that's what some of the fancy
require/provide/defsystem things do already.
--tim
>>>>> "Bj�rn" == Bj�rn Lindberg <·······@nada.kth.se> writes:
Bj�rn> The matlisp source directory also contains "dfftpack.system" and
Bj�rn> "lapack.system", but no "matlisp.system". Is the "blas.system" still
Bj�rn> the major matlisp defsystem file?
That there is not matlisp.system file is an historical artifact. What
you're looking for is system.dcl.
>> The mk:defsystem library can be used to load/compile the systems it
>> knows about, by using the function OPERATE-ON-SYSTEM (or OOS for
>> short). For example, you can load matlisp by evaluating
>>
>> * (mk:oos :blas :load)
Bj�rn> So, assuming the package is in place, with logical pathnames properly
Bj�rn> set up, this is the equivalent of a C #include statement or a module
Bj�rn> loading statement in some other language?
>> If you look at the blas.system file, you'll notice that it uses
>> logical pathnames:
>>
>> | (mk:defsystem blas
>> | :source-pathname "matlisp:blas;"
>> | ...
>>
>> That tells mk:defsystem to look for the source files in the directory
>> "blas" on the logical host "matlisp". AFAIK, setting up appropriate
>> LOGICAL-PATHNAME-TRANSLATIONs is up to the user. Again, the startup
>> file would be an appropriate place.
Bj�rn> This sounds like it's more trouble than benefit, but I guess there is
Bj�rn> some good reason to why this logical pathname indirection is being
Bj�rn> used.
You can load "start.lisp" from anywhere and, I think, all of the
relevant logical pathname translations will be set up for you
automatically.
Ray